From nobody Mon Feb 1 12:06:35 2021 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 021C23A142D; Mon, 1 Feb 2021 12:06:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161220999394.5511.3827477021770602766@ietfa.amsl.com> Date: Mon, 01 Feb 2021 12:06:34 -0800 Archived-At: Subject: [GNAP] Grant Negotiation and Authorization Protocol (gnap) WG Virtual Meeting: 2021-02-10 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 20:06:34 -0000 The Grant Negotiation and Authorization Protocol (gnap) WG will hold a virtual interim meeting on 2021-02-10 from 18:00 to 19:00 Asia/Jerusalem (16:00 to 17:00 UTC). Agenda: TBD Information about remote participation: https://intuit.zoom.us/j/99481776837?from=addon From nobody Thu Feb 4 03:12:46 2021 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 A789C3A1265 for ; Thu, 4 Feb 2021 03:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 K4d9D2S9jLMx for ; Thu, 4 Feb 2021 03:12:41 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 8C1593A1262 for ; Thu, 4 Feb 2021 03:12:41 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id n2so2728808iom.7 for ; Thu, 04 Feb 2021 03:12:41 -0800 (PST) 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=mqTRxbIX5lFG7C56ZFRpaH4vZxqRYn1qGP1O/kQY+iY=; b=AjA03XopRS077484YvnZNtL5x0/TQa3EjShLR4vsdotUlt5Z/nPKDJJMADORf/kHC5 qXr56XXHabC0+DAiXpveR+3EEC5oxJBoig+vLOFttfN/SpgYn2HMIDxNVlkm9w1VzZEF VNfKjtwGgUPGS3xH/yOpV8PQXKPb36FWaptZHYol9jGIiwF84m4UOXsQupCjTp8Oj0vP RTIIrnrbkhU9luiMt/FNbzgvbEO+Asow2f5InIN23fivUi8IFmkMoBmjUOIJmRfuTOkU nIvA+JrzED/hkiEhQ5T/XDrv4WoyYbD1PtIJWNhmfkSXQ/K2fdvsu58ukX6NcZcCcg8y r6mQ== 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=mqTRxbIX5lFG7C56ZFRpaH4vZxqRYn1qGP1O/kQY+iY=; b=Piv3T6gLdUhFC9EmnQsJo6snrpCJ+vWNnRoQ8Gpkc5bj/0DkB8I1bks5xUA0W1jbME DNTXv6XQhj4BlxiF+5JKUPl5sAn5JW3d8ZrCWnc3ZW2u4h1wIp3tizUVObe1v66G8nkc vG1tE/AeaEV0GyZbbU9FrTA2sAOwVlLvswwgn4gqpufxXxh2uRN6Rf/BkMrkKISs+VTm Y5pcXIBV7NjdR3/h73Z5ly/oVconCS/3yAee+Ddjjfyyeb5Ppa110YgVoD8TXIlmQ17D 1MFjSGfkAJijiydOCMrhRV3m71nGMowOtNxCJT5uJ5udKgYtHBxVA5qbd0xC1qeLlCEg a24A== X-Gm-Message-State: AOAM533N5xSuMhcqASw2McmIj87CX4HWRf2W4h/m/qvD0xdUKCAYTmbt PB5npz6yUNbQjMlfcMzjW84qrLozan9YKViJ9pc= X-Google-Smtp-Source: ABdhPJxJ0jzsWohhQu0cZE6KjFQmnEaILa0SoRSJ3DCvsk0Lb8xlVsK27U05EPzVfeLcCPGx26U7/ZeSz8wwQZJYG2w= X-Received: by 2002:a6b:510d:: with SMTP id f13mr539682iob.141.1612437160718; Thu, 04 Feb 2021 03:12:40 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: From: Fabien Imbault Date: Thu, 4 Feb 2021 12:12:27 +0100 Message-ID: To: Francis Pouatcha Cc: GNAP Mailing List , Dick Hardt , Tom Jones , Denis , Justin Richer Content-Type: multipart/alternative; boundary="0000000000002ff2eb05ba80c8fb" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 11:12:45 -0000 --0000000000002ff2eb05ba80c8fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Francis, I've tried a few things with regards to using the AS on a phone, but it's really quite complex. Making that run on a phone comes with quite a bit of trouble. The most difficult part if that we'd need to use a secure element, but just installing and hosting a http server securely is not a standard setup at all. I suggest interested people step in to work on this, as we already have a lot of work for the (more usual) server case and already handle a privacy preserving scheme. Please let us know what you think. Cheers, Fabien On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault wrote: > Hi Francis, > > I've thought a bit more to what you said. I think I'll give it a try as a > separate experiment (in code, not in theory). Not that I would expect it = to > be included in GNAP, but I kind of like the idea :-) > > The direct impact for GNAP would be to think about multiple ASs. > > Will let you know. > > Fabien > > > Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha a = =C3=A9crit : > >> It would be nice if the protocol was designed at many layers of >> abstraction. >> >> >> - The first layer shall design abstract protocol flows, without >> specification of the mode and mechanism of interaction. >> - The second layer can instantiate the first layer for dedicated >> interaction. Here we can talk http, we can define interactions that p= resume >> server based token generation, we can define interaction that run on = user >> device based token generation. >> >> This is also the fundament of the structure I proposed for the spec ( >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). >> >> /Francis >> >> ------------------------------ >> *From:* Fabien Imbault >> *Sent:* Wednesday, November 18, 2020 6:35 AM >> *To:* Francis Pouatcha >> *Cc:* txauth@ietf.org ; Dick Hardt ; >> Tom Jones ; Denis ; >> Justin Richer >> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >> >> Would make sense, but not so easy as we rely heavily on HTTP. Hence the >> discussion about deep links and so on. >> >> An alternative might be provided by wasm/wasi (running a local sandbox o= n >> your phone, for your own AS), but it's really early stage. This also pos= es >> another question that Denis has put forward, i.e. how do we handle the >> multiple AS scenario (likely to occur then). >> >> Fabien >> >> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha wrote= : >> >> We are drifting away from the original problem space. >> >> - My original mention was about the "POST" request, that subsumes >> that the "AS" is a "Server". Designing a new protocol, we cannot affo= rd >> this limitation. >> - I just mentioned SIOP to show a known and closed example? Let us >> not focus on the device local discovery scheme (like openid:) for now= . >> - As capability of holding private keys on user device evolves, >> server-based issuing of token will be fading out giving way to device= local >> generation of token. >> >> While designing GNAP, let us assume the AS-Role can be exercised on a >> user device and design the protocol to honor that. >> >> Best regards, >> /Francis >> ------------------------------ >> *From:* TXAuth on behalf of Dick Hardt < >> dick.hardt@gmail.com> >> *Sent:* Tuesday, November 17, 2020 1:28 PM >> *To:* Tom Jones >> *Cc:* Fabien Imbault ; Denis < >> denis.ietf@free.fr>; GNAP Mailing List ; Justin Richer = < >> jricher@mit.edu> >> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >> >> Got it. >> >> So web apps invoke a openid: deep link and hope there is an app to handl= e >> the openid: scheme? ... and that it is the user's wallet rather than som= e >> malware that has registered openid: on the mobile device? >> >> A native app can attempt to open a deep link associated with an app, and >> will fail if the app is not there. If the app is there, it will be opene= d, >> so this can't be used to silently test if an app is present, but it does >> allow a native app to provide an alternative experience if an app is not >> present. I don't think this works with custom schemes ... and I don't kn= ow >> how it could work from a web app on the phone with the current Safari AP= Is. >> >> Apple warns against using custom schemes [1] ... but perhaps they can be >> convinced to make openid: a managed scheme similar to mailto:, tel:, >> sms:, facetime: ? >> >> [1] >> https://developer.apple.com/documentation/xcode/allowing_apps_and_websit= es_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app >> >> >> =E1=90=A7 >> >> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones >> wrote: >> >> You are - that is not standard which is opeind:// >> This is the one step that still needs to be optimized for SIOP to have >> good UX. >> Peace ..tom >> >> >> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt wrote: >> >> Hi Tom >> >> I watched your video (I watched at 2X speed) >> >> Looks like the employment website app that is using localhost:8765 to >> communicate with the wallet. Am I correct? >> >> /Dick >> =E1=90=A7 >> >> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones >> wrote: >> >> Well, here's a demo. Note that in this case the AS is not online all of >> the time, so it is really implicit flow and the OIDC id-token comes from >> the siop device directly. >> (whether this is front-channel or back channel is no longer an >> interesting question.) >> Now if an always-on AS is required, that is possible, but probably beyon= d >> the scope of this effort and would require something like an >> agent-in-the-sky (with diamonds). >> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 >> >> Peace ..tom >> >> >> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: >> >> Ultimately, in most situations like these in the real world, the hurdle >> isn=E2=80=99t technical compatibility so much as it is trust compatibili= ty. The RP >> (client) needs to have some incentive to trust the assertions and identi= ty >> information that=E2=80=99s coming from the AS. The same is true for an R= S trusting >> tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to d= o that (which SSI >> answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, >> because it=E2=80=99s a hard question). >> >> Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on >> device=E2=80=9D element. We=E2=80=99ve got the start of it more than OAu= th2/OIDC have by >> allowing the bootstrap of the process from a starting call: the interact= ion >> and continuation URIs handed back by the AS don=E2=80=99t need to be the= same URIs >> that the client starts with, so just like SIOP the process can start in >> HTTP and potentially move to other communication channels. A major >> difference is that we aren=E2=80=99t dependent on the assumption that th= e user will >> always be in a browser at some stage, and so the whole raft of >> front-channel messages that SIOP relies on doesn=E2=80=99t fly. That sai= d, we=E2=80=99ve >> got an opportunity to more explicitly open up alternative communication >> channels here, and that=E2=80=99s something I=E2=80=99d like to see engi= neered, even if >> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete proposal a= s to how that would >> work over specific protocols, starting with what we=E2=80=99ve got today= . >> >> =E2=80=94 Justin >> >> On Nov 17, 2020, at 12:03 PM, Fabien Imbault >> wrote: >> >> Hi Denis, hi Francis, >> >> At some point integration with SSI (on the authentication side) will >> probably occur, including amongst other possibilities SIOP (since they w= ork >> with OpenID a part of the work will probably be made easier). >> >> That being said, Denis is right. It's not an AS. Technically it's >> entirely possible to rely on a decentralized wallet (for instance on you= r >> phone) and a centralized AS. I know of a few studies on how to decentral= ize >> the AS itself (for instance >> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >> Maybe it exists, but I'm still looking for real scenarios (or even >> architectures) where an AS is deployed directly on a phone, and under th= e >> sole authority of the RO, while being compatible with the rest of the >> world. >> >> Cheers, >> Fabien >> >> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >> >> Hello Francis, >> >> See two comments in line. >> >> >> B) Current Document >> >> Roles description shall not hold any assumption on the physical structur= e >> of the party fulfilling the roles. >> [FI] not sure what you mean >> >> [FP] for example, we assume the AS is a server! In most SSI based use >> cases, the AS will be running on the user device. See SIOP ( >> https://identity.foundation/did-siop/). >> >> I browsed through the two drafts, i.e. : >> >> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >> model, and representations W3C Working Draft 08 November 2020 >> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working >> Group Draft >> >> At no place within these two documents, it is possible to imagine that >> "the AS will be running on the user device". >> >> From section 3 of the DIF Working Group Draft: >> >> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the >> SIOP will not return an access token to the RP". >> >> An Identity Wallet is not an AS. >> >> >> Roles: >> -> grant endpoint of the AS: Why is this a post request? This eliminates >> the chance of having user device hosted AS (no server). >> [FI] what would you propose instead? >> Would also be interested to understand better the deployment model when >> there is no server. That's something that was discussed several times bu= t >> I'm still missing the underlying architecture and use case. >> >> [FP] See above (SIOP). There will be a lot of identity wallets operated >> on end user device. >> >> See the above comment. Please, do not confuse an Identity Wallet with an >> Authentication Server (AS). >> >> Denis >> >> >> -> Resource Owner (RO) : Authorizes the request? Does it authorize the >> request or the access to a resource? >> [FI] yes, we should make the wording clearer >> >> Missing Section Interactions: >> --> This section shall introduce the notion of interaction before we >> start listing interaction types. >> [FI] yes >> >> Interaction Types: >> --> I prefer a classification with Redirect, Decoupled and Embedded is. >> In the draft, we have one redirect and 2 decouple interactions and nothi= ng >> else. >> [FI] this should be handled as a specific discussion item. As a reminder= , >> how would you define embedded? >> >> In practice there's at least these modes: >> - redirect and redirect back >> - redirect to different browser or device >> - user code >> - CIBA >> >> [FP] This classification is limited. >> >> - Redirect: same device, same or different user agents (browser, >> mobile app, desktop app, ...) >> - Decoupled: different devices >> - Embedded : RC carries RO authorization to AS >> >> >> >> Resource Access Request vs. Resource Request >> --> Both are mixed up. No clarification of the context of each section. >> [FI] could you clarify what you'd expect. Btw on this topic, there's a >> more general discussion on whether we should make a distinction or not. >> >> =E2=80=8B[FP]: Here: >> >> - Resource Access Request: Requesting Access to a resource. Response >> is an access token (or any type of grant) >> - Resource Request: Request the resource. Response is the resource >> (or a corresponding execution) >> >> >> Token Content Negotiation >> --> Not expressed as such. This is central to GNAP and not represented >> enough in the document. >> [FI] right. This should be a specific discussion item. >> >> Requesting "User" Information >> we identify two types of users: RQ and RO. It will be better not to refe= r >> to a user in this draft, but either to a RQ or an RO. >> [FI] yes that would avoid potential misunderstandings. Although in the >> end, people will translate RQ into user or end-user most of the time. Cf= in >> definition, currently we have Requesting Party (RQ, aka "user") >> >> >> Interaction Again >> -> For each interaction type, we will have to describe the protocol flow >> and the nature and behavior of involved Roles (Parties), Elements, Reque= sts. >> [FI] yes >> >> >> [FP] Will these and into tickets? >> >> Best regards. >> /Francis >> >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> --0000000000002ff2eb05ba80c8fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francis,=C2=A0

I've tried a few = things with regards to using the AS on a phone, but it's really quite= =C2=A0complex.=C2=A0

Making that run on a phone co= mes with quite a bit of trouble. The most difficult part if that we'd n= eed to use a secure element, but just installing and hosting a http server = securely is not a standard setup at all. I suggest interested people step i= n to work on this, as we already have a lot of work for the (more usual) se= rver case and already handle a privacy preserving scheme.=C2=A0
<= br>
Please let us know what you think.

C= heers,
Fabien=C2=A0

On Tue, Nov 24, 2020 at 5:55 AM Fabien I= mbault <fabien.imbault@gmail= .com> wrote:
Hi Francis,

I've thought a bit more to what you said. I think I'll gi= ve it a try as a separate experiment (in code, not in theory). Not that I w= ould expect it to be included in GNAP, but I kind of like the idea :-)

The direct impact for GNAP w= ould be to think about multiple ASs.=C2=A0

Will let you know.=C2=A0

Fabien=C2=A0


Le mer. 18 nov. 2020 =C3=A0 13:06, Fran= cis Pouatcha <fpo@ad= orsys.de> a =C3=A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"gmail-m_142651873244800559m_8348797445460806175LPlnk338391" rel=3D"nore= ferrer" target=3D"_blank">https://github.com/ietf-wg-gnap/gnap-core-protoco= l/issues/30).

/Francis

From: Fabien Imbault <fabien.imbault@gmail.com= >
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>; Dick Hardt <dick= .hardt@gmail.com>; Tom Jones <thomasclinganjones@gmail.= com>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@m= it.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@ador= sys.de> wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <tx= auth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis= <denis.ietf@free.fr>; GNAP Mailing List <txauth@ietf.org>= ; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <t= homasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hard= t@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <th= omasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.= be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mi= t.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@= gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.= fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop= /).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possible to imagine that &= quot;the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code = Flow as per [OIDC.Core], the SIOP will not return an access token to the RP= ".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity Wallet with an= Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= =E2=80=8B= [FP]: Here:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--0000000000002ff2eb05ba80c8fb-- From nobody Thu Feb 4 03:35:06 2021 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 8965E3A12C9 for ; Thu, 4 Feb 2021 03:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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] 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 kJfYxyEsKbrQ for ; Thu, 4 Feb 2021 03:35:03 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 06F573A12C8 for ; Thu, 4 Feb 2021 03:35:03 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id u20so2776274iot.9 for ; Thu, 04 Feb 2021 03:35:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=E7WDMxQfsStiohicTb/jPxSQvMcOjY3cdjzc5BXPc0E=; b=NYJ9QvX0zmvwmuh928zwZGuQf87YACV3EXy0Cfw6G8ZhcqOLQiKnt4qNltkFd0wCYe 6ky7eLBZRFaqlIj8PGiaA5y/xOpRY4MLyTYyts3pAMWMPKhLkWDLE43zX4G8LJzZQfVF qOgz9bI6aaK4SnYXyFM9Dc2eANsQuCefEJ4/y9Hfwqr5aefD7qh85NqYXvSzueCzKTF+ QV+PTyJWm1rH7P20PGGV/BhQTx25GPJj5rehuG4sBNcrwZFF9pBlMAxTi3sD+3d0EOpu SGaOnPfnvLY1I2YhvsyydVAkAKJVT1B0YbPY5y83ppr/dDZ6+vjAAX3MsJ0XLv3kwP+Z LWZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=E7WDMxQfsStiohicTb/jPxSQvMcOjY3cdjzc5BXPc0E=; b=l7bcOWnmGlNqljkjuReqfRiSaYX+DrXU2wyQIuXfEdjoWJ/ZAtAX5pOxuRC5F7bCyr Wzg+GCRVCraW2mq0O8qA90EAcdcMDFvKmoCxO+XfFEk5ikkiwqo60gt08snjf3H6p1xX 86Vp/yfgqXROcTX5yn5sGpRK1oqfiS9TNKIbvWCgJLEZsjwbHE+wD7ZdsWOWBJhSnBr7 eTd2Bbq1gMXqEI4fj3ePCKKf6t9gSInOAH19U49Ofu3bc9N3lD7vwp2n0Z/bZ530YZSd QF9weTRTuT1kEEksOyAxsU51My2fBA4m3SB/3qHu+g9kVYMqWD0voY+WfUawygyDEgBi UJOQ== X-Gm-Message-State: AOAM532WzBnrwJhYf/UAZ8e8d62U7O/6tmtv9NCMyz3f+KtU8oM36YbD PMGqwlp227uWvmQCeHqTSv4o6W/UAmZQI1Z1ESEEwjcOsfSiOA== X-Google-Smtp-Source: ABdhPJynhNRU9AeBOsEofU2DPullXu5+9SzgkRhLNpxkWHyxOWKMSjcZq0bX+aGs51rR1/GEvW2gyovV++iwX9OluEQ= X-Received: by 2002:a02:5148:: with SMTP id s69mr7705825jaa.8.1612438501671; Thu, 04 Feb 2021 03:35:01 -0800 (PST) MIME-Version: 1.0 From: Fabien Imbault Date: Thu, 4 Feb 2021 12:34:48 +0100 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000001d493905ba8118d1" Archived-At: Subject: [GNAP] PR 143 and 162 pending merge X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 11:35:05 -0000 --0000000000001d493905ba8118d1 Content-Type: text/plain; charset="UTF-8" Hi all, The editors met yesterday evening to process the outstanding issues and PRs. Please find a summary of the changes : 2 PRs are now pending merge : Replace 'MUST ... if possible' with SHOULD. https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/143 Reformat access token request and response format. https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/162 As per our established process, these will be merged after 7 days if there are no further comments on the PRs. One PR (https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/4) was closed without merging and replaced by a dedicated issue. Create JSON Schema https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/166 We also reviewed the issues marked "pending close" or "needs text". Since none of them have received further comments, we closed them or will close them asap (for those where editorial changes are required as a consequence). This concerns: - Unique callback URIs (#55) - closed - Reading the state of a request (#98) - editorial change and will be closed - Updating and reading access tokens (#99) - editorial change and will be closed Last there are a few other editorial cleanups to make, in particular we'll remove the links to already closed issues in the spec (issues #29, #55, #106). Best regards, Justin, Aaron and Fabien --0000000000001d493905ba8118d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

The=C2=A0editors=C2=A0met yesterday evening to process the outs= tanding issues and PRs. Please find a summary of the changes :=C2=A0
<= div>
2 PRs are now pending merge :=C2=A0

=
Replace 'MUST ... if possible' with SHOULD.=C2=A0
h= ttps://github.com/ietf-wg-gnap/gnap-core-protocol/pull/143=C2=A0

Reformat access token request and response format.

As per our established process, these will be m= erged after 7 days if there are no further comments on the PRs.
<= br>
Create JSON Schema

We also reviewed the issu= es marked "pending close" or "needs text". Since none o= f them have received further comments, we closed them or will close them as= ap (for those where editorial changes are required as a consequence).
=
This concerns:=C2=A0
-=C2=A0Unique callback URIs (#55) - clo= sed
- Reading the state of a request (#98) - editorial change and= will be closed
-=C2=A0Updating and reading access tokens (#9= 9) - editorial change and will be closed
Last there are a few oth= er editorial cleanups to=C2=A0make, in particular we'll remove the=C2= =A0links to already closed issues in the spec (issues #29, #55, #106).

Best regards,=C2=A0
Justin, Aaron and Fabien=
--0000000000001d493905ba8118d1-- From nobody Thu Feb 4 05:08:56 2021 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 C674D3A143C for ; Thu, 4 Feb 2021 05:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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] 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 B-fESs7uhYA6 for ; Thu, 4 Feb 2021 05:08:54 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 512253A143A for ; Thu, 4 Feb 2021 05:08:54 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id g9so2518382ilc.3 for ; Thu, 04 Feb 2021 05:08:54 -0800 (PST) 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; bh=ezHYQRzxJNrRtf7HEj70QR2bq+aHwLyVvFxCqZn4C1Y=; b=LZaxIzu1UrP1FA6IPzKLodEUpfudmV4Sb6RHn7TvcfBVBJm33BLFX04VzvtjsKMi/P 1qR0wDWOHQ7uV35G75zP68S5lxQwA5zRD3FzJt8Wdbai7SzVZavfNqBgP2k0rFLEHBwK 7XVXaLSUyDWh+B714AsaWwGrVcAeZUiiQo6U68NH9qjiku79/qJRQ/6aPsKwzG6vCSgT fdA9SGGpu5Hf6vXt5K2piDmjcNOehzrb+9jmEARR0sQbIAa8GgjZNoUDd4Ch10+mFQS6 FcjGX/V6apN4Had0jZkV5PnH6h5WSboBTaao1KxohKE8TMlfPU0Hd0iYZ+ZM/vLrJiwg qDzg== 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; bh=ezHYQRzxJNrRtf7HEj70QR2bq+aHwLyVvFxCqZn4C1Y=; b=cWbG3eU7xtAcEzQwNBIrXS/kcZrzFCuZBLFwfwzI0Z4Jz94gUWd88JEd8wM6xk3HLv lEYTZy/PQ61b7qvZzCVYTOflrwchoOcpHPyaC6WyG/X5SyVsrP7zOGC+JHolrWTLIO4m ODxfdxcYcANkgn8hzbkbfUF2Ce3loRJObFmEt9PPf4M3hSGuwpvUIENelRaXohAQTGxN SCeg8JAXRUcKGvwOjiH/BCm1FbKzX/lCJfHs7vWlLuebnSjzwit53HW2JmUURWEz+KKi DJCYn0354owbZUh7y0oA+CAzVAoT5zmK+XS6QfTjJEBk4CBnDnVB7Or6n367lsi6t5Od 7LIA== X-Gm-Message-State: AOAM531lxcn+LkFB3fjBtwE5cSjbvYXlKlAZxzkKrFYgyiXi7j2Z7gqy 5jZOihHfuhu/zjH9ie6LLk52l5RB8H1WmAoMkl7vDPI83Cp6GA== X-Google-Smtp-Source: ABdhPJzpBe8w7mIHB84WAQGPl0ozQSmGX1DI7BxejPD1u52ahG2aP0cTJUwQxgD+w1/ZPrb9rJ3DHPoOZJQEBj0hEUE= X-Received: by 2002:a05:6e02:b4e:: with SMTP id f14mr6587351ilu.289.1612444133356; Thu, 04 Feb 2021 05:08:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Thu, 4 Feb 2021 14:08:39 +0100 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000c9fa1c05ba826794" Archived-At: Subject: Re: [GNAP] git/github tutorial for GNAP X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 13:08:56 -0000 --000000000000c9fa1c05ba826794 Content-Type: text/plain; charset="UTF-8" Hi there, The tutorial is completed https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Git-tutorial Feedbacks are welcome, especially from people unfamiliar with the tool. Best regards Fabien On Thu, Jan 28, 2021 at 3:13 PM Fabien Imbault wrote: > Hi there, > > Based on feedback received, we'll start by a wiki to explain. The goal is > to help everyone with issues, PRs etc. We'll only focus on what is > important in the context of GNAP. > > Here's the link : > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Git-tutorial > (of course it's just a starting point). > > Feel free to contribute and enrich the content. > Cheers. > > Fabien > > On Wed, Jan 27, 2021 at 12:39 PM Fabien Imbault > wrote: > >> Hi everyone, >> >> The chairs and editors have communicated at various occasions on how/why >> we use github. Some of you asked for more information as to how to >> participate to issues, PR etc. So we'd propose a short training relative to >> git/github and its use for the GNAP working group. >> The date still needs to be defined but I can guess we could use a 30min >> window at the end of a scheduled meeting. The goal is to record it so that >> newcomers can refer if needed. >> >> Please let us know if there are specific questions that you'd like to be >> covered. >> >> Best >> Fabien >> >> >> --000000000000c9fa1c05ba826794 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,=C2=A0


Feedbacks are welcome, especially = from people unfamiliar with the tool.

Best regards=
Fabien

On Thu, Jan 28, 2021 at 3:13 PM Fabien Imbault <<= a href=3D"mailto:fabien.imbault@gmail.com">fabien.imbault@gmail.com>= wrote:
Hi there,=C2=A0

Based on feedback received,= we'll start by a wiki to explain. The goal is to help everyone with is= sues, PRs etc. We'll only focus on what is important in the context of = GNAP.

(of course it's just a starting point).

Feel free to contribute and enrich the content.=C2=A0
Ch= eers.

Fabien

On Wed, Jan 27, 2021 at 12:39 PM= Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi everyone,

=
The chairs and editors have communicated at various occasions on= how/why we use github. Some of you asked for more information as to how to= participate to=C2=A0issues, PR etc. So we'd propose a short training r= elative=C2=A0to git/github and its use for the GNAP working group.
The date still needs to be defined but I can guess we could use a 30min w= indow at the end of a scheduled meeting. The goal is to record it so that n= ewcomers can refer if needed.

Please let us know i= f there are specific questions that you'd like to be covered.

Best
Fabien


--000000000000c9fa1c05ba826794-- From nobody Thu Feb 4 05:35:22 2021 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 596F53A148C for ; Thu, 4 Feb 2021 05:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 pF6UmQZJ8oWo for ; Thu, 4 Feb 2021 05:35:17 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 B21443A1363 for ; Thu, 4 Feb 2021 05:35:17 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id u20so3149649iot.9 for ; Thu, 04 Feb 2021 05:35:17 -0800 (PST) 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=lIu1zgxTZ2vVfEo6boHRsryGans7HF4ziDzThntXfaA=; b=iR6l/SaE09aR5v8AiftwzmzChmxuyjmEco7t/9XBfkeym2qdWcgxCJGrhSXrc9Wny2 926OWGN3/Wf3TVz7ekqvWQdvQOV2YKDRBwsbR3L6zZBQCITdN6hv8H6T9ZWqPMgytYCV CazNEYIXzEvskPRWvQzNiCI5cSD0DAZM184L+Eco6D4HY1jITfPZbNWcaNcXT5e118X2 cMNRWDPWB89OGGVhAM1jZsZnkMB6D21ZqyaPNq/kjiZ1FqVGrsGZg26Wacl3kVcSSlPP 1cHJG802OFMCs6R/+y39Z9GpZDE9RxLh3BPul3KgAyqv6ZJxOimuxi4a8ocb6868TtTu SQDg== 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=lIu1zgxTZ2vVfEo6boHRsryGans7HF4ziDzThntXfaA=; b=Qi3kTKik6v0PT18UsuOLcn4Sbt78udPh5XbhhOMV6xfbNucY3ADSQ1NlU8Ja9KneQ7 uC+oDW7vRTK6gIiyY6AteYv1F1dSBLFSvnX52iXT8p6N2NxaKA20J09z4wFRT8t6CBmq nqCCXDnPvX5FYtlpzoeUU2n90Rtwr6cCsmdb69BfM+tIVLC4t2b/7U4tYaVkRI3I8XHD I9Zbqif46eh8ddc53nqSDSvOywZNR3yGu3bu/QffKi9ZZRDrlSWDINBbNGTMpaO1NK4/ 5iaTi1FItTDP6Rv0Ezxke9tQyarl63niOXM7TJ421j/2PAn69Rxe5DE+FmEcatpCFmxe VDVg== X-Gm-Message-State: AOAM530CiZHez11JMMlbaKaHOf/PfiOoazFcP6RxcYWYAbVL46uCfY4U 9fRh1hYfBMfdCdNDhDVIDC4c+IGWoSlCd+YDBcU= X-Google-Smtp-Source: ABdhPJxVn2LeARQn1k8ir8cDya2bLfCJ1W6bXSH7whDDtf5A2JS0zgDXsP6XQ6vaWmLmB7H/xRsXNe5z/QXU7O73EjE= X-Received: by 2002:a6b:680e:: with SMTP id d14mr1025346ioc.74.1612445716890; Thu, 04 Feb 2021 05:35:16 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: From: Fabien Imbault Date: Thu, 4 Feb 2021 14:35:03 +0100 Message-ID: To: Tom Jones Cc: Francis Pouatcha , GNAP Mailing List , Dick Hardt , Denis , Justin Richer Content-Type: multipart/alternative; boundary="0000000000002cca0e05ba82c691" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 13:35:21 -0000 --0000000000002cca0e05ba82c691 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tom, Sure, any experience on that would be greatly appreciated, we're calling for help here (the point being that I suspect what they're doing is not trivial). Fabien On Thu, Feb 4, 2021 at 2:21 PM Tom Jones wrote: > I've had such an app working for over a year. There are issues which are > being addressed by the browser Interaction team of oidc. > > thx ..Tom (mobile) > > On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault > wrote: > >> Hi Francis, >> >> I've tried a few things with regards to using the AS on a phone, but it'= s >> really quite complex. >> >> Making that run on a phone comes with quite a bit of trouble. The most >> difficult part if that we'd need to use a secure element, but just >> installing and hosting a http server securely is not a standard setup at >> all. I suggest interested people step in to work on this, as we already >> have a lot of work for the (more usual) server case and already handle a >> privacy preserving scheme. >> >> Please let us know what you think. >> >> Cheers, >> Fabien >> >> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault >> wrote: >> >>> Hi Francis, >>> >>> I've thought a bit more to what you said. I think I'll give it a try as >>> a separate experiment (in code, not in theory). Not that I would expect= it >>> to be included in GNAP, but I kind of like the idea :-) >>> >>> The direct impact for GNAP would be to think about multiple ASs. >>> >>> Will let you know. >>> >>> Fabien >>> >>> >>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha a >>> =C3=A9crit : >>> >>>> It would be nice if the protocol was designed at many layers of >>>> abstraction. >>>> >>>> >>>> - The first layer shall design abstract protocol flows, without >>>> specification of the mode and mechanism of interaction. >>>> - The second layer can instantiate the first layer for dedicated >>>> interaction. Here we can talk http, we can define interactions that= presume >>>> server based token generation, we can define interaction that run o= n user >>>> device based token generation. >>>> >>>> This is also the fundament of the structure I proposed for the spec ( >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). >>>> >>>> /Francis >>>> >>>> ------------------------------ >>>> *From:* Fabien Imbault >>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>> *To:* Francis Pouatcha >>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>> dick.hardt@gmail.com>; Tom Jones ; Denis >>>> ; Justin Richer >>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>> >>>> Would make sense, but not so easy as we rely heavily on HTTP. Hence th= e >>>> discussion about deep links and so on. >>>> >>>> An alternative might be provided by wasm/wasi (running a local sandbox >>>> on your phone, for your own AS), but it's really early stage. This als= o >>>> poses another question that Denis has put forward, i.e. how do we hand= le >>>> the multiple AS scenario (likely to occur then). >>>> >>>> Fabien >>>> >>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha >>>> wrote: >>>> >>>> We are drifting away from the original problem space. >>>> >>>> - My original mention was about the "POST" request, that subsumes >>>> that the "AS" is a "Server". Designing a new protocol, we cannot af= ford >>>> this limitation. >>>> - I just mentioned SIOP to show a known and closed example? Let us >>>> not focus on the device local discovery scheme (like openid:) for n= ow. >>>> - As capability of holding private keys on user device evolves, >>>> server-based issuing of token will be fading out giving way to devi= ce local >>>> generation of token. >>>> >>>> While designing GNAP, let us assume the AS-Role can be exercised on a >>>> user device and design the protocol to honor that. >>>> >>>> Best regards, >>>> /Francis >>>> ------------------------------ >>>> *From:* TXAuth on behalf of Dick Hardt < >>>> dick.hardt@gmail.com> >>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>> *To:* Tom Jones >>>> *Cc:* Fabien Imbault ; Denis < >>>> denis.ietf@free.fr>; GNAP Mailing List ; Justin >>>> Richer >>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>> >>>> Got it. >>>> >>>> So web apps invoke a openid: deep link and hope there is an app to >>>> handle the openid: scheme? ... and that it is the user's wallet rather= than >>>> some malware that has registered openid: on the mobile device? >>>> >>>> A native app can attempt to open a deep link associated with an app, >>>> and will fail if the app is not there. If the app is there, it will be >>>> opened, so this can't be used to silently test if an app is present, b= ut it >>>> does allow a native app to provide an alternative experience if an app= is >>>> not present. I don't think this works with custom schemes ... and I do= n't >>>> know how it could work from a web app on the phone with the current Sa= fari >>>> APIs. >>>> >>>> Apple warns against using custom schemes [1] ... but perhaps they can >>>> be convinced to make openid: a managed scheme similar to mailto:, >>>> tel:, sms:, facetime: ? >>>> >>>> [1] >>>> https://developer.apple.com/documentation/xcode/allowing_apps_and_webs= ites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app >>>> >>>> >>>> =E1=90=A7 >>>> >>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>> thomasclinganjones@gmail.com> wrote: >>>> >>>> You are - that is not standard which is opeind:// >>>> This is the one step that still needs to be optimized for SIOP to have >>>> good UX. >>>> Peace ..tom >>>> >>>> >>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt >>>> wrote: >>>> >>>> Hi Tom >>>> >>>> I watched your video (I watched at 2X speed) >>>> >>>> Looks like the employment website app that is using localhost:8765 to >>>> communicate with the wallet. Am I correct? >>>> >>>> /Dick >>>> =E1=90=A7 >>>> >>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones >>>> wrote: >>>> >>>> Well, here's a demo. Note that in this case the AS is not online all o= f >>>> the time, so it is really implicit flow and the OIDC id-token comes fr= om >>>> the siop device directly. >>>> (whether this is front-channel or back channel is no longer an >>>> interesting question.) >>>> Now if an always-on AS is required, that is possible, but probably >>>> beyond the scope of this effort and would require something like an >>>> agent-in-the-sky (with diamonds). >>>> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 >>>> >>>> Peace ..tom >>>> >>>> >>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: >>>> >>>> Ultimately, in most situations like these in the real world, the hurdl= e >>>> isn=E2=80=99t technical compatibility so much as it is trust compatibi= lity. The RP >>>> (client) needs to have some incentive to trust the assertions and iden= tity >>>> information that=E2=80=99s coming from the AS. The same is true for an= RS trusting >>>> tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to= do that (which SSI >>>> answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn= =E2=80=99t answer very well, >>>> because it=E2=80=99s a hard question). >>>> >>>> Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on >>>> device=E2=80=9D element. We=E2=80=99ve got the start of it more than O= Auth2/OIDC have by >>>> allowing the bootstrap of the process from a starting call: the intera= ction >>>> and continuation URIs handed back by the AS don=E2=80=99t need to be t= he same URIs >>>> that the client starts with, so just like SIOP the process can start i= n >>>> HTTP and potentially move to other communication channels. A major >>>> difference is that we aren=E2=80=99t dependent on the assumption that = the user will >>>> always be in a browser at some stage, and so the whole raft of >>>> front-channel messages that SIOP relies on doesn=E2=80=99t fly. That s= aid, we=E2=80=99ve >>>> got an opportunity to more explicitly open up alternative communicatio= n >>>> channels here, and that=E2=80=99s something I=E2=80=99d like to see en= gineered, even if >>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete proposal= as to how that would >>>> work over specific protocols, starting with what we=E2=80=99ve got tod= ay. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault >>>> wrote: >>>> >>>> Hi Denis, hi Francis, >>>> >>>> At some point integration with SSI (on the authentication side) will >>>> probably occur, including amongst other possibilities SIOP (since they= work >>>> with OpenID a part of the work will probably be made easier). >>>> >>>> That being said, Denis is right. It's not an AS. Technically it's >>>> entirely possible to rely on a decentralized wallet (for instance on y= our >>>> phone) and a centralized AS. I know of a few studies on how to decentr= alize >>>> the AS itself (for instance >>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >>>> Maybe it exists, but I'm still looking for real scenarios (or even >>>> architectures) where an AS is deployed directly on a phone, and under = the >>>> sole authority of the RO, while being compatible with the rest of the >>>> world. >>>> >>>> Cheers, >>>> Fabien >>>> >>>> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >>>> >>>> Hello Francis, >>>> >>>> See two comments in line. >>>> >>>> >>>> B) Current Document >>>> >>>> Roles description shall not hold any assumption on the physical >>>> structure of the party fulfilling the roles. >>>> [FI] not sure what you mean >>>> >>>> [FP] for example, we assume the AS is a server! In most SSI based use >>>> cases, the AS will be running on the user device. See SIOP ( >>>> https://identity.foundation/did-siop/). >>>> >>>> I browsed through the two drafts, i.e. : >>>> >>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >>>> model, and representations W3C Working Draft 08 November 2020 >>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working >>>> Group Draft >>>> >>>> At no place within these two documents, it is possible to imagine that >>>> "the AS will be running on the user device". >>>> >>>> From section 3 of the DIF Working Group Draft: >>>> >>>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the >>>> SIOP will not return an access token to the RP". >>>> >>>> An Identity Wallet is not an AS. >>>> >>>> >>>> Roles: >>>> -> grant endpoint of the AS: Why is this a post request? This >>>> eliminates the chance of having user device hosted AS (no server). >>>> [FI] what would you propose instead? >>>> Would also be interested to understand better the deployment model whe= n >>>> there is no server. That's something that was discussed several times = but >>>> I'm still missing the underlying architecture and use case. >>>> >>>> [FP] See above (SIOP). There will be a lot of identity wallets >>>> operated on end user device. >>>> >>>> See the above comment. Please, do not confuse an Identity Wallet with >>>> an Authentication Server (AS). >>>> >>>> Denis >>>> >>>> >>>> -> Resource Owner (RO) : Authorizes the request? Does it authorize the >>>> request or the access to a resource? >>>> [FI] yes, we should make the wording clearer >>>> >>>> Missing Section Interactions: >>>> --> This section shall introduce the notion of interaction before we >>>> start listing interaction types. >>>> [FI] yes >>>> >>>> Interaction Types: >>>> --> I prefer a classification with Redirect, Decoupled and Embedded is= . >>>> In the draft, we have one redirect and 2 decouple interactions and not= hing >>>> else. >>>> [FI] this should be handled as a specific discussion item. As a >>>> reminder, how would you define embedded? >>>> >>>> In practice there's at least these modes: >>>> - redirect and redirect back >>>> - redirect to different browser or device >>>> - user code >>>> - CIBA >>>> >>>> [FP] This classification is limited. >>>> >>>> - Redirect: same device, same or different user agents (browser, >>>> mobile app, desktop app, ...) >>>> - Decoupled: different devices >>>> - Embedded : RC carries RO authorization to AS >>>> >>>> >>>> >>>> Resource Access Request vs. Resource Request >>>> --> Both are mixed up. No clarification of the context of each section= . >>>> [FI] could you clarify what you'd expect. Btw on this topic, there's = a >>>> more general discussion on whether we should make a distinction or not= . >>>> >>>> =E2=80=8B[FP]: Here: >>>> >>>> - Resource Access Request: Requesting Access to a resource. >>>> Response is an access token (or any type of grant) >>>> - Resource Request: Request the resource. Response is the resource >>>> (or a corresponding execution) >>>> >>>> >>>> Token Content Negotiation >>>> --> Not expressed as such. This is central to GNAP and not represented >>>> enough in the document. >>>> [FI] right. This should be a specific discussion item. >>>> >>>> Requesting "User" Information >>>> we identify two types of users: RQ and RO. It will be better not to >>>> refer to a user in this draft, but either to a RQ or an RO. >>>> [FI] yes that would avoid potential misunderstandings. Although in the >>>> end, people will translate RQ into user or end-user most of the time. = Cf in >>>> definition, currently we have Requesting Party (RQ, aka "user") >>>> >>>> >>>> Interaction Again >>>> -> For each interaction type, we will have to describe the protocol >>>> flow and the nature and behavior of involved Roles (Parties), Elements= , >>>> Requests. >>>> [FI] yes >>>> >>>> >>>> [FP] Will these and into tickets? >>>> >>>> Best regards. >>>> /Francis >>>> >>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> --0000000000002cca0e05ba82c691 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,=C2=A0

Sure, any experience on t= hat would be greatly appreciated, we're calling for help here (the poin= t being that I suspect what they're doing is not trivial).
Fabien

On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com= > wrote:
I've had such an app working for over a year. There are i= ssues which are being addressed by the browser Interaction team of oidc.
thx ..Tom (mobile)

On Thu, Feb 4, 2021, 3:12 AM Fabien Imbau= lt <fabien= .imbault@gmail.com> wrote:
Hi Francis,=C2=A0

I&#= 39;ve tried a few things with regards to using the AS on a phone, but it= 9;s really quite=C2=A0complex.=C2=A0

Making that r= un on a phone comes with quite a bit of trouble. The most difficult part if= that we'd need to use a secure element, but just installing and hostin= g a http server securely is not a standard setup at all. I suggest interest= ed people step in to work on this, as we already have a lot of work for the= (more usual) server case and already handle a privacy preserving scheme.= =C2=A0

Please let us know what you think.

Cheers,
Fabien=C2=A0

On Tue, Nov 24, 2020= at 5:55 AM Fabien Imbault <fabien.imbault@gmail.com> wrote= :
Hi Francis,

I've = thought a bit more to what you said. I think I'll give it a try as a se= parate experiment (in code, not in theory). Not that I would expect it to b= e included in GNAP, but I kind of like the idea :-)
=
The direct impact for GNAP would be to think ab= out multiple ASs.=C2=A0

= Will let you know.=C2=A0

Fabien=C2=A0


Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha <fpo@ad= orsys.de> a =C3=A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"gmail-m_-3342024782330569254m_8014700032835912204gmail-m_14265187324480= 0559m_8348797445460806175LPlnk338391" rel=3D"noreferrer noreferrer" target= =3D"_blank">https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: = Fabien Imbault <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>;= Dick Hardt <dick.hardt@gmail.com>; Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-bounces@iet= f.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com<= /a>>
Cc: Fabien Imbault <fabien.imbault@gmail.com= >; Denis <denis.ietf@free.fr>; GNAP Mailing List &l= t;txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://yo= utu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabi= en.imbault@gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentralized= -02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis= .ietf@free.fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundati= on/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possible to imagine that &= quot;the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code = Flow as per [OIDC.Core], the SIOP will not return an access token to the RP= ".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity Wallet with an= Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= =E2=80=8B= [FP]: Here:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--0000000000002cca0e05ba82c691-- From nobody Thu Feb 4 06:15:46 2021 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 4A9823A14ED for ; Thu, 4 Feb 2021 06:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.505 X-Spam-Level: X-Spam-Status: No, score=-0.505 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, MALFORMED_FREEMAIL=1.591, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 6MgQZOVY-TUE for ; Thu, 4 Feb 2021 06:15:42 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 918553A14EC for ; Thu, 4 Feb 2021 06:15:42 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id q7so3620978wre.13 for ; Thu, 04 Feb 2021 06:15:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=w9mCf8ROO7wGpUTVeEe42GSBL8ZiXVMTRXpv64jIfxI=; b=da2f+AclVx+cOxFsWgj5HwQgFw5CENldJhs9gf8IV6rMvFNEeh1LGkfLNdUnMSVMSt b0m8x8/v4rPn3Laa8lQ5onZrIzUL5Cbwx5Oz93eP56p5aiVhtpP1s6c0URvBeUOrPdRb nSX7hx9z4RFLR06zmrrNW1ohmVejhTPBgxOuG4WASYL7Dyvl/iVv6Gm34y0vPg8Vbja5 i8lYekUL/KveqFf5HbUeRDyHSlxre8rasq7tzHZl7aMBhu9f/+QKe1J3vRz2uPyJGBWz pKvwKHkzz20GhzUwjrZKfYWCj1Mkvmcze0Xv8foSpE8jz/o5oSdcS8qs9VvTEcqPy1os +rXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=w9mCf8ROO7wGpUTVeEe42GSBL8ZiXVMTRXpv64jIfxI=; b=LF0cISvNFwrnzV7jpdk0JJqCeQdq0b4/pfqa5ilR7CzkDNjjDHxJ2/sg/RU0zs5dfE oFziJODyNDdahQF90QhuxqE6o7ZTkTHn3p0Mu6P4AmNKkq4tct5Eg6WUcH2CswQ85eAN uLWUnpF69qD6s8apvyh7l3lLkTkwDpSub8aJ2/hqxwECV4Wo17pwMsRH4CopZUAGp1BL FojgRjuttrFxHtccb0OYSo89pAzzepmEB8Hix0IvnzbHDnk2fU+mjHzqZIQSyLj/dhmN 84wJjke8Zu34EXBUSuuRDvIpSrYwA097WyCEmk5aNKCM6qH4svzl4XYcN59Cgh9T7yZZ CLLw== X-Gm-Message-State: AOAM531W8ri+qoYzUiB779/5tPIQyjGgk1cs1g8l3hpaXWPBKeheNx8j 2wU4traYrLX2Gm8GDFsdv4M= X-Google-Smtp-Source: ABdhPJwx/6m39Fieooldlkl4t8UaQASM6jxhzI6wwuK7D58ZcUz0vxNoGoSl8ascIJqbonEDtf4gbQ== X-Received: by 2002:a5d:4d8b:: with SMTP id b11mr9663005wru.215.1612448141134; Thu, 04 Feb 2021 06:15:41 -0800 (PST) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id 67sm6393175wmz.46.2021.02.04.06.15.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Feb 2021 06:15:40 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.45.21011103 Date: Thu, 04 Feb 2021 16:15:39 +0200 From: Yaron Sheffer To: Fabien Imbault , GNAP Mailing List Message-ID: <003E7632-17E7-4E43-A8CB-E900A4C18E79@gmail.com> Thread-Topic: [GNAP] git/github tutorial for GNAP References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3695300140_1415673747" Archived-At: Subject: Re: [GNAP] git/github tutorial for GNAP X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 14:15:44 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3695300140_1415673747 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Thank you for this contribution Fabien! You might want to share with the Ed= u Team: https://datatracker.ietf.org/group/edu/about/ =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: TXAuth on behalf of Fabien Imbault Date: Thursday, February 4, 2021 at 15:09 To: GNAP Mailing List Subject: Re: [GNAP] git/github tutorial for GNAP =20 Hi there,=20 =20 The tutorial is completed https://github.com/ietf-wg-gnap/gnap-core-protoco= l/wiki/Git-tutorial =20 Feedbacks are welcome, especially from people unfamiliar with the tool. =20 Best regards Fabien =20 On Thu, Jan 28, 2021 at 3:13 PM Fabien Imbault w= rote: Hi there,=20 =20 Based on feedback received, we'll start by a wiki to explain. The goal is t= o help everyone with issues, PRs etc. We'll only focus on what is important = in the context of GNAP. =20 Here's the link : https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/G= it-tutorial (of course it's just a starting point). =20 Feel free to contribute and enrich the content.=20 Cheers. =20 Fabien =20 On Wed, Jan 27, 2021 at 12:39 PM Fabien Imbault = wrote: Hi everyone, =20 The chairs and editors have communicated at various occasions on how/why we= use github. Some of you asked for more information as to how to participate= to issues, PR etc. So we'd propose a short training relative to git/github = and its use for the GNAP working group. The date still needs to be defined but I can guess we could use a 30min win= dow at the end of a scheduled meeting. The goal is to record it so that newc= omers can refer if needed. =20 Please let us know if there are specific questions that you'd like to be co= vered. =20 Best Fabien =20 =20 -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3695300140_1415673747 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Thank you for this co= ntribution Fabien! You might want to share with the Edu Team: https://datatracker.ietf.org/group= /edu/about/

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

From: TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imbault &l= t;fabien.imbault@gmail.com>
Date: Thursday, February 4, 2021 at= 15:09
To: GNAP Mailing List <txauth@ietf.org>
Subject= : Re: [GNAP] git/github tutorial for GNAP

 

Hi t= here, 

 

=

 

F= eedbacks are welcome, especially from people unfamiliar with the tool.<= /o:p>

 

Best regards

Fabie= n

 

On Thu, Jan 28, 2021 at 3:13 PM Fabien Imbault <fabien.imbault@gmail.com> wrote= :

=

Hi there, 

 

Based on feedback received, = we'll start by a wiki to explain. The goal is to help everyone with issues, = PRs etc. We'll only focus on what is important in the context of GNAP.<= /o:p>

 

(of course it's just a starting point).

<= /div>

 

Feel free to contribute and enrich the content. 

Cheers.

 

Fabien

 

On Wed, Jan 27, 2021 at 12:39 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:=

<= p class=3DMsoNormal>Hi everyone,

&n= bsp;

The chairs and editors have comm= unicated at various occasions on how/why we use github. Some of you asked fo= r more information as to how to participate to issues, PR etc. So we'd = propose a short training relative to git/github and its use for the GNA= P working group.

The date still = needs to be defined but I can guess we could use a 30min window at the end o= f a scheduled meeting. The goal is to record it so that newcomers can refer = if needed.

 

=

Please let us know if there are specific quest= ions that you'd like to be covered.

 

Best

Fabien

 

 

<= /div>

-- TXAut= h mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =

--B_3695300140_1415673747-- From nobody Thu Feb 4 07:04:13 2021 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 252353A157A for ; Thu, 4 Feb 2021 07:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ag0iQM9lNBhI for ; Thu, 4 Feb 2021 07:04:10 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9193A1577 for ; Thu, 4 Feb 2021 07:04:10 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 114F47oN015137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 4 Feb 2021 10:04:08 -0500 From: Justin Richer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 4 Feb 2021 10:04:07 -0500 References: <161220999394.5511.3827477021770602766@ietfa.amsl.com> To: txauth gnap In-Reply-To: <161220999394.5511.3827477021770602766@ietfa.amsl.com> Message-Id: <8E3D2DB4-BD58-455E-9215-36FA3B7A4485@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Grant Negotiation and Authorization Protocol (gnap) WG Virtual Meeting: 2021-02-10 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 15:04:12 -0000 Agenda, from the editor team: - Review of changes since IETF109 (including edits since -03) - Interaction mode changes (issue #122) - Discussion of next steps =E2=80=94 Justin > On Feb 1, 2021, at 3:06 PM, IESG Secretary = wrote: >=20 > The Grant Negotiation and Authorization Protocol (gnap) WG will hold > a virtual interim meeting on 2021-02-10 from 18:00 to 19:00 = Asia/Jerusalem (16:00 to 17:00 UTC). >=20 > Agenda: > TBD >=20 > Information about remote participation: > https://intuit.zoom.us/j/99481776837?from=3Daddon >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Thu Feb 4 07:23:18 2021 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 9715C3A146B for ; Thu, 4 Feb 2021 05:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 IIZ2qtboqnLl for ; Thu, 4 Feb 2021 05:22:00 -0800 (PST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 CB1A23A1467 for ; Thu, 4 Feb 2021 05:21:59 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id e70so3301445ote.11 for ; Thu, 04 Feb 2021 05:21:59 -0800 (PST) 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=vo42+jxy6OObQevMNMYLb2k8mrmPQy/TKuE5O+UlcJw=; b=jdhCn/QDI+O1m2ZzUEbP3VH4l4qlirZJ/9IX7MAFoIDisaxR2Y7yl6wKlsexytmLMx a1MTyF73YXvDNRKs3vQRI4HUIlyedVl7/16wqj4JKrxbxFYQrkGLpNemaK1Oc9f4T5Bz +y+CNTlRxDboGMwnCCmG0o1Hk8nkdTh7iod4aElbuCTWieQvmsOps/sK/a4Emx0as5G3 8ftRaKhL/riWuixqdB47CjQGGaUfWAGEdXgKMl1ZENqha0bPiPblvZPo15we65XCAQJq tRqVk+nxbK6HlM97du6xEqCjlyZov9aO+ZHvwwNfg5EM4sg4zTEcTsgTGEJijeHjNEYi OFCw== 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=vo42+jxy6OObQevMNMYLb2k8mrmPQy/TKuE5O+UlcJw=; b=lkKtW/DEzL+BLwJ/PddT5kL6roeLedf7g6sbpHqWOiRLQKSQVWJB7LWCVkdXg+KxqP KicNMo/KH+OeBTrysCRGEisORO62OYYBVwnDLtGNdttUnOEE6apZU37gRABpdoWMXEUO LH30eHuSbi8+RIsldLYyZmzExesrkWXR+fogiuVlsLSMNR9/uyhVhAU4Fy5seAbcE61l 7s/yQzPoYvL/lnzRhSFGvQ7r1HNai8tC1SGbG46HtEEUClB6Lm5TS9kzPgWAp13G1unG QljQvy+B22J51YrotW772kRy/aYXp+dz9N0OAU+dNi9QzVePMEovfypqImRuNh733JCV JELw== X-Gm-Message-State: AOAM5327oIdTO3rdYF1EBx0pqiSRWwmliJPweJrjL7JPlNccOiTkIT3N 79weyuhtW6nqMSgBkpAvT/Vnu11VfVxKyFy7TBc= X-Google-Smtp-Source: ABdhPJwyT2yTaqlF4eDK+qUIHk5yP6AxpLksjNKYOg16nY81Cc9sj9ipMiIGFBcHsCfB/9LjN02fcO8by+xZC7PPGII= X-Received: by 2002:a9d:3b87:: with SMTP id k7mr5631903otc.143.1612444918897; Thu, 04 Feb 2021 05:21:58 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: From: Tom Jones Date: Thu, 4 Feb 2021 05:21:47 -0800 Message-ID: To: Fabien Imbault Cc: Francis Pouatcha , GNAP Mailing List , Dick Hardt , Denis , Justin Richer Content-Type: multipart/alternative; boundary="0000000000009c5fc405ba8296ec" Archived-At: X-Mailman-Approved-At: Thu, 04 Feb 2021 07:23:17 -0800 Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 13:22:04 -0000 --0000000000009c5fc405ba8296ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've had such an app working for over a year. There are issues which are being addressed by the browser Interaction team of oidc. thx ..Tom (mobile) On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault wrote: > Hi Francis, > > I've tried a few things with regards to using the AS on a phone, but it's > really quite complex. > > Making that run on a phone comes with quite a bit of trouble. The most > difficult part if that we'd need to use a secure element, but just > installing and hosting a http server securely is not a standard setup at > all. I suggest interested people step in to work on this, as we already > have a lot of work for the (more usual) server case and already handle a > privacy preserving scheme. > > Please let us know what you think. > > Cheers, > Fabien > > On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault > wrote: > >> Hi Francis, >> >> I've thought a bit more to what you said. I think I'll give it a try as = a >> separate experiment (in code, not in theory). Not that I would expect it= to >> be included in GNAP, but I kind of like the idea :-) >> >> The direct impact for GNAP would be to think about multiple ASs. >> >> Will let you know. >> >> Fabien >> >> >> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha a = =C3=A9crit : >> >>> It would be nice if the protocol was designed at many layers of >>> abstraction. >>> >>> >>> - The first layer shall design abstract protocol flows, without >>> specification of the mode and mechanism of interaction. >>> - The second layer can instantiate the first layer for dedicated >>> interaction. Here we can talk http, we can define interactions that = presume >>> server based token generation, we can define interaction that run on= user >>> device based token generation. >>> >>> This is also the fundament of the structure I proposed for the spec ( >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). >>> >>> /Francis >>> >>> ------------------------------ >>> *From:* Fabien Imbault >>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>> *To:* Francis Pouatcha >>> *Cc:* txauth@ietf.org ; Dick Hardt < >>> dick.hardt@gmail.com>; Tom Jones ; Denis = < >>> denis.ietf@free.fr>; Justin Richer >>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>> >>> Would make sense, but not so easy as we rely heavily on HTTP. Hence the >>> discussion about deep links and so on. >>> >>> An alternative might be provided by wasm/wasi (running a local sandbox >>> on your phone, for your own AS), but it's really early stage. This also >>> poses another question that Denis has put forward, i.e. how do we handl= e >>> the multiple AS scenario (likely to occur then). >>> >>> Fabien >>> >>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha >>> wrote: >>> >>> We are drifting away from the original problem space. >>> >>> - My original mention was about the "POST" request, that subsumes >>> that the "AS" is a "Server". Designing a new protocol, we cannot aff= ord >>> this limitation. >>> - I just mentioned SIOP to show a known and closed example? Let us >>> not focus on the device local discovery scheme (like openid:) for no= w. >>> - As capability of holding private keys on user device evolves, >>> server-based issuing of token will be fading out giving way to devic= e local >>> generation of token. >>> >>> While designing GNAP, let us assume the AS-Role can be exercised on a >>> user device and design the protocol to honor that. >>> >>> Best regards, >>> /Francis >>> ------------------------------ >>> *From:* TXAuth on behalf of Dick Hardt < >>> dick.hardt@gmail.com> >>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>> *To:* Tom Jones >>> *Cc:* Fabien Imbault ; Denis < >>> denis.ietf@free.fr>; GNAP Mailing List ; Justin Richer >>> >>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>> >>> Got it. >>> >>> So web apps invoke a openid: deep link and hope there is an app to >>> handle the openid: scheme? ... and that it is the user's wallet rather = than >>> some malware that has registered openid: on the mobile device? >>> >>> A native app can attempt to open a deep link associated with an app, an= d >>> will fail if the app is not there. If the app is there, it will be open= ed, >>> so this can't be used to silently test if an app is present, but it doe= s >>> allow a native app to provide an alternative experience if an app is no= t >>> present. I don't think this works with custom schemes ... and I don't k= now >>> how it could work from a web app on the phone with the current Safari A= PIs. >>> >>> Apple warns against using custom schemes [1] ... but perhaps they can b= e >>> convinced to make openid: a managed scheme similar to mailto:, tel:, >>> sms:, facetime: ? >>> >>> [1] >>> https://developer.apple.com/documentation/xcode/allowing_apps_and_websi= tes_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app >>> >>> >>> =E1=90=A7 >>> >>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones >>> wrote: >>> >>> You are - that is not standard which is opeind:// >>> This is the one step that still needs to be optimized for SIOP to have >>> good UX. >>> Peace ..tom >>> >>> >>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt wrote= : >>> >>> Hi Tom >>> >>> I watched your video (I watched at 2X speed) >>> >>> Looks like the employment website app that is using localhost:8765 to >>> communicate with the wallet. Am I correct? >>> >>> /Dick >>> =E1=90=A7 >>> >>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones >>> wrote: >>> >>> Well, here's a demo. Note that in this case the AS is not online all of >>> the time, so it is really implicit flow and the OIDC id-token comes fro= m >>> the siop device directly. >>> (whether this is front-channel or back channel is no longer an >>> interesting question.) >>> Now if an always-on AS is required, that is possible, but probably >>> beyond the scope of this effort and would require something like an >>> agent-in-the-sky (with diamonds). >>> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 >>> >>> Peace ..tom >>> >>> >>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: >>> >>> Ultimately, in most situations like these in the real world, the hurdle >>> isn=E2=80=99t technical compatibility so much as it is trust compatibil= ity. The RP >>> (client) needs to have some incentive to trust the assertions and ident= ity >>> information that=E2=80=99s coming from the AS. The same is true for an = RS trusting >>> tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to = do that (which SSI >>> answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, >>> because it=E2=80=99s a hard question). >>> >>> Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on >>> device=E2=80=9D element. We=E2=80=99ve got the start of it more than OA= uth2/OIDC have by >>> allowing the bootstrap of the process from a starting call: the interac= tion >>> and continuation URIs handed back by the AS don=E2=80=99t need to be th= e same URIs >>> that the client starts with, so just like SIOP the process can start in >>> HTTP and potentially move to other communication channels. A major >>> difference is that we aren=E2=80=99t dependent on the assumption that t= he user will >>> always be in a browser at some stage, and so the whole raft of >>> front-channel messages that SIOP relies on doesn=E2=80=99t fly. That sa= id, we=E2=80=99ve >>> got an opportunity to more explicitly open up alternative communication >>> channels here, and that=E2=80=99s something I=E2=80=99d like to see eng= ineered, even if >>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete proposal = as to how that would >>> work over specific protocols, starting with what we=E2=80=99ve got toda= y. >>> >>> =E2=80=94 Justin >>> >>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault >>> wrote: >>> >>> Hi Denis, hi Francis, >>> >>> At some point integration with SSI (on the authentication side) will >>> probably occur, including amongst other possibilities SIOP (since they = work >>> with OpenID a part of the work will probably be made easier). >>> >>> That being said, Denis is right. It's not an AS. Technically it's >>> entirely possible to rely on a decentralized wallet (for instance on yo= ur >>> phone) and a centralized AS. I know of a few studies on how to decentra= lize >>> the AS itself (for instance >>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >>> Maybe it exists, but I'm still looking for real scenarios (or even >>> architectures) where an AS is deployed directly on a phone, and under t= he >>> sole authority of the RO, while being compatible with the rest of the >>> world. >>> >>> Cheers, >>> Fabien >>> >>> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >>> >>> Hello Francis, >>> >>> See two comments in line. >>> >>> >>> B) Current Document >>> >>> Roles description shall not hold any assumption on the physical >>> structure of the party fulfilling the roles. >>> [FI] not sure what you mean >>> >>> [FP] for example, we assume the AS is a server! In most SSI based use >>> cases, the AS will be running on the user device. See SIOP ( >>> https://identity.foundation/did-siop/). >>> >>> I browsed through the two drafts, i.e. : >>> >>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >>> model, and representations W3C Working Draft 08 November 2020 >>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working >>> Group Draft >>> >>> At no place within these two documents, it is possible to imagine that >>> "the AS will be running on the user device". >>> >>> From section 3 of the DIF Working Group Draft: >>> >>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the >>> SIOP will not return an access token to the RP". >>> >>> An Identity Wallet is not an AS. >>> >>> >>> Roles: >>> -> grant endpoint of the AS: Why is this a post request? This eliminate= s >>> the chance of having user device hosted AS (no server). >>> [FI] what would you propose instead? >>> Would also be interested to understand better the deployment model when >>> there is no server. That's something that was discussed several times b= ut >>> I'm still missing the underlying architecture and use case. >>> >>> [FP] See above (SIOP). There will be a lot of identity wallets operate= d >>> on end user device. >>> >>> See the above comment. Please, do not confuse an Identity Wallet with a= n >>> Authentication Server (AS). >>> >>> Denis >>> >>> >>> -> Resource Owner (RO) : Authorizes the request? Does it authorize the >>> request or the access to a resource? >>> [FI] yes, we should make the wording clearer >>> >>> Missing Section Interactions: >>> --> This section shall introduce the notion of interaction before we >>> start listing interaction types. >>> [FI] yes >>> >>> Interaction Types: >>> --> I prefer a classification with Redirect, Decoupled and Embedded is. >>> In the draft, we have one redirect and 2 decouple interactions and noth= ing >>> else. >>> [FI] this should be handled as a specific discussion item. As a >>> reminder, how would you define embedded? >>> >>> In practice there's at least these modes: >>> - redirect and redirect back >>> - redirect to different browser or device >>> - user code >>> - CIBA >>> >>> [FP] This classification is limited. >>> >>> - Redirect: same device, same or different user agents (browser, >>> mobile app, desktop app, ...) >>> - Decoupled: different devices >>> - Embedded : RC carries RO authorization to AS >>> >>> >>> >>> Resource Access Request vs. Resource Request >>> --> Both are mixed up. No clarification of the context of each section. >>> [FI] could you clarify what you'd expect. Btw on this topic, there's a >>> more general discussion on whether we should make a distinction or not. >>> >>> =E2=80=8B[FP]: Here: >>> >>> - Resource Access Request: Requesting Access to a resource. Response >>> is an access token (or any type of grant) >>> - Resource Request: Request the resource. Response is the resource >>> (or a corresponding execution) >>> >>> >>> Token Content Negotiation >>> --> Not expressed as such. This is central to GNAP and not represented >>> enough in the document. >>> [FI] right. This should be a specific discussion item. >>> >>> Requesting "User" Information >>> we identify two types of users: RQ and RO. It will be better not to >>> refer to a user in this draft, but either to a RQ or an RO. >>> [FI] yes that would avoid potential misunderstandings. Although in the >>> end, people will translate RQ into user or end-user most of the time. C= f in >>> definition, currently we have Requesting Party (RQ, aka "user") >>> >>> >>> Interaction Again >>> -> For each interaction type, we will have to describe the protocol flo= w >>> and the nature and behavior of involved Roles (Parties), Elements, Requ= ests. >>> [FI] yes >>> >>> >>> [FP] Will these and into tickets? >>> >>> Best regards. >>> /Francis >>> >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> --0000000000009c5fc405ba8296ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've had such an app working for over a year. There a= re issues which are being addressed by the browser Interaction team of oidc= .

thx ..Tom (mobile)

On= Thu, Feb 4, 2021, 3:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,=C2=A0

I= 've tried a few things with regards to using the AS on a phone, but it&= #39;s really quite=C2=A0complex.=C2=A0

Making that= run on a phone comes with quite a bit of trouble. The most difficult part = if that we'd need to use a secure element, but just installing and host= ing a http server securely is not a standard setup at all. I suggest intere= sted people step in to work on this, as we already have a lot of work for t= he (more usual) server case and already handle a privacy preserving scheme.= =C2=A0

Please let us know what you think.

Cheers,
Fabien=C2=A0

On Tue, Nov 24, 2020= at 5:55 AM Fabien Imbault <fabien.imbault@gmail.com> wrote= :
Hi Francis,

I've = thought a bit more to what you said. I think I'll give it a try as a se= parate experiment (in code, not in theory). Not that I would expect it to b= e included in GNAP, but I kind of like the idea :-)
=
The direct impact for GNAP would be to think ab= out multiple ASs.=C2=A0

= Will let you know.=C2=A0

Fabien=C2=A0


Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha <fpo@ad= orsys.de> a =C3=A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"m_8014700032835912204gmail-m_142651873244800559m_8348797445460806175LPl= nk338391" rel=3D"noreferrer noreferrer" target=3D"_blank">https://github.co= m/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>;= Dick Hardt <dick.hardt@gmail.com>; Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-bounces@ietf.org> on behalf of D= ick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com<= /a>>
Cc: Fabien Imbault <fabien.imbault@gmail.com= >; Denis <denis.ietf@free.fr>; GNAP Mailing List &l= t;txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://yo= utu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabi= en.imbault@gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentralized= -02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis= .ietf@free.fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundati= on/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possible to imagine that &= quot;the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code = Flow as per [OIDC.Core], the SIOP will not return an access token to the RP= ".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity Wallet with an= Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= =E2=80=8B= [FP]: Here:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--0000000000009c5fc405ba8296ec-- From nobody Thu Feb 4 07:30:36 2021 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 60F383A15BA for ; Thu, 4 Feb 2021 07:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, PDS_SHORTFWD_URISHRT_QP=1.498, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 XyNlZsxRkvD7 for ; Thu, 4 Feb 2021 07:30:31 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244243A15B8 for ; Thu, 4 Feb 2021 07:30:30 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 114FUMdd031256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 4 Feb 2021 10:30:22 -0500 From: Justin Richer Message-Id: <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_76024558-1412-4ACE-89FD-FAD697C5AB41" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 4 Feb 2021 10:30:22 -0500 In-Reply-To: Cc: Tom Jones , Francis Pouatcha , GNAP Mailing List , Dick Hardt , Denis To: Fabien Imbault References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 15:30:35 -0000 --Apple-Mail=_76024558-1412-4ACE-89FD-FAD697C5AB41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 One of the biggest drawbacks of the current app-centric approaches in = OIDC (self-issued OP, or SIOP) is that they depend on using the front = channel and browser redirects to pass everything, which is something = that GNAP is deliberately getting away from by starting in the back = channel. That said, once a request is kicked off in GNAP, the interaction and = fulfillment can happen through any number of means. Part of the work = that=E2=80=99s being done with the =E2=80=9Cinteraction=E2=80=9D section = is going to help facilitate this, and I think that there are some other = potential branches here. Token delivery is where things get extra weird though =E2=80=94 we are = explicitly not delivering tokens in the front channel in the core of = GNAP, we=E2=80=99re using the response from the continuation API. One = idea (that isn=E2=80=99t particularly well thought out and hasn=E2=80=99t = been implemented at all) is to have an extension declare an alternative = response from the =E2=80=9Ccontinue=E2=80=9D section that=E2=80=99s = defined today, which points to the GNPA continuation API. If an = extension defines some alternative way to deliver tokens, that could = live alongside a continuation API and the client could indicate support = for it in its initial request. In any event, alternative interaction and delivery methods are = important, and even if we aren=E2=80=99t going to support every last one = of them directly, the protocol design should at least be aware of them. =E2=80=94 Justin > On Feb 4, 2021, at 8:35 AM, Fabien Imbault = wrote: >=20 > Hi Tom,=20 >=20 > Sure, any experience on that would be greatly appreciated, we're = calling for help here (the point being that I suspect what they're doing = is not trivial). >=20 > Fabien >=20 > On Thu, Feb 4, 2021 at 2:21 PM Tom Jones > wrote: > I've had such an app working for over a year. There are issues which = are being addressed by the browser Interaction team of oidc. >=20 > thx ..Tom (mobile) >=20 > On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault > wrote: > Hi Francis,=20 >=20 > I've tried a few things with regards to using the AS on a phone, but = it's really quite complex.=20 >=20 > Making that run on a phone comes with quite a bit of trouble. The most = difficult part if that we'd need to use a secure element, but just = installing and hosting a http server securely is not a standard setup at = all. I suggest interested people step in to work on this, as we already = have a lot of work for the (more usual) server case and already handle a = privacy preserving scheme.=20 >=20 > Please let us know what you think. >=20 > Cheers, > Fabien=20 >=20 > On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault = > wrote: > Hi Francis, >=20 > I've thought a bit more to what you said. I think I'll give it a try = as a separate experiment (in code, not in theory). Not that I would = expect it to be included in GNAP, but I kind of like the idea :-) >=20 > The direct impact for GNAP would be to think about multiple ASs.=20 >=20 > Will let you know.=20 >=20 > Fabien=20 >=20 >=20 > Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha > a =C3=A9crit : > It would be nice if the protocol was designed at many layers of = abstraction. >=20 > The first layer shall design abstract protocol flows, without = specification of the mode and mechanism of interaction. > The second layer can instantiate the first layer for dedicated = interaction. Here we can talk http, we can define interactions that = presume server based token generation, we can define interaction that = run on user device based token generation. > This is also the fundament of the structure I proposed for the spec = (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30 = ). >=20 > /Francis >=20 > From: Fabien Imbault > > Sent: Wednesday, November 18, 2020 6:35 AM > To: Francis Pouatcha > > Cc: txauth@ietf.org >; Dick Hardt >; Tom Jones >; Denis >; Justin Richer > > Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > =20 > Would make sense, but not so easy as we rely heavily on HTTP. Hence = the discussion about deep links and so on. >=20 > An alternative might be provided by wasm/wasi (running a local sandbox = on your phone, for your own AS), but it's really early stage. This also = poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=20 >=20 > Fabien=20 >=20 > On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha > wrote: > We are drifting away from the original problem space. > My original mention was about the "POST" request, that subsumes that = the "AS" is a "Server". Designing a new protocol, we cannot afford this = limitation. > I just mentioned SIOP to show a known and closed example? Let us not = focus on the device local discovery scheme (like openid:) for now. > As capability of holding private keys on user device evolves, = server-based issuing of token will be fading out giving way to device = local generation of token. > While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that. >=20 > Best regards, > /Francis > From: TXAuth > on behalf of Dick Hardt = > > Sent: Tuesday, November 17, 2020 1:28 PM > To: Tom Jones > > Cc: Fabien Imbault >; Denis >; GNAP Mailing List >; Justin Richer > > Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > =20 > Got it.=20 >=20 > So web apps invoke a openid: deep link and hope there is an app to = handle the openid: scheme? ... and that it is the user's wallet rather = than some malware that has registered openid: on the mobile device? >=20 > A native app can attempt to open a deep link associated with an app, = and will fail if the app is not there. If the app is there, it will be = opened, so this can't be used to silently test if an app is present, but = it does allow a native app to provide an alternative experience if an = app is not present. I don't think this works with custom schemes ... and = I don't know how it could work from a web app on the phone with the = current Safari APIs. >=20 > Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, = sms:, facetime: ? >=20 > [1] = https://developer.apple.com/documentation/xcode/allowing_apps_and_websites= _to_link_to_your_content/defining_a_custom_url_scheme_for_your_app = >=20 >=20 > =E1=90=A7 >=20 > On Tue, Nov 17, 2020 at 10:06 AM Tom Jones = > = wrote: > You are - that is not standard which is opeind:// > This is the one step that still needs to be optimized for SIOP to have = good UX. > Peace ..tom >=20 >=20 > On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt > wrote: > Hi Tom >=20 > I watched your video (I watched at 2X speed) >=20 > Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct? >=20 > /Dick=20 > =E1=90=A7 >=20 > On Tue, Nov 17, 2020 at 9:46 AM Tom Jones = > = wrote: > Well, here's a demo. Note that in this case the AS is not online all = of the time, so it is really implicit flow and the OIDC id-token comes = from the siop device directly. > (whether this is front-channel or back channel is no longer an = interesting question.) > Now if an always-on AS is required, that is possible, but probably = beyond the scope of this effort and would require something like an = agent-in-the-sky (with diamonds). > here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 = > Peace ..tom >=20 >=20 > On Tue, Nov 17, 2020 at 9:20 AM Justin Richer > wrote: > Ultimately, in most situations like these in the real world, the = hurdle isn=E2=80=99t technical compatibility so much as it is trust = compatibility. The RP (client) needs to have some incentive to trust the = assertions and identity information that=E2=80=99s coming from the AS. = The same is true for an RS trusting tokens from the AS. The hard = question is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), = but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t = answer very well, because it=E2=80=99s a hard question). >=20 > Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of = it more than OAuth2/OIDC have by allowing the bootstrap of the process = from a starting call: the interaction and continuation URIs handed back = by the AS don=E2=80=99t need to be the same URIs that the client starts = with, so just like SIOP the process can start in HTTP and potentially = move to other communication channels. A major difference is that we = aren=E2=80=99t dependent on the assumption that the user will always be = in a browser at some stage, and so the whole raft of front-channel = messages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve= got an opportunity to more explicitly open up alternative communication = channels here, and that=E2=80=99s something I=E2=80=99d like to see = engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a = concrete proposal as to how that would work over specific protocols, = starting with what we=E2=80=99ve got today.=20 >=20 > =E2=80=94 Justin >=20 >> On Nov 17, 2020, at 12:03 PM, Fabien Imbault = > wrote: >>=20 >> Hi Denis, hi Francis,=20 >>=20 >> At some point integration with SSI (on the authentication side) will = probably occur, including amongst other possibilities SIOP (since they = work with OpenID a part of the work will probably be made easier).=20 >>=20 >> That being said, Denis is right. It's not an AS. Technically it's = entirely possible to rely on a decentralized wallet (for instance on = your phone) and a centralized AS. I know of a few studies on how to = decentralize the AS itself (for instance = https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02 = ). >> Maybe it exists, but I'm still looking for real scenarios (or even = architectures) where an AS is deployed directly on a phone, and under = the sole authority of the RO, while being compatible with the rest of = the world.=20 >>=20 >> Cheers, >> Fabien >>=20 >> On Tue, Nov 17, 2020 at 5:45 PM Denis > wrote: >> Hello Francis, >>=20 >> See two comments in line. >>=20 >>>=20 >>> B) Current Document >>>=20 >>> Roles description shall not hold any assumption on the physical = structure of the party fulfilling the roles. >>> [FI] not sure what you mean >>> [FP] for example, we assume the AS is a server! In most SSI based = use cases, the AS will be running on the user device. See SIOP = (https://identity.foundation/did-siop/ = ). >> I browsed through the two drafts, i.e. : >>=20 >> Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, = and representations W3C Working Draft 08 November 2020 >> Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft >> At no place within these two documents, it is possible to imagine = that "the AS will be running on the user device". >>=20 >> =46rom section 3 of the DIF Working Group Draft: >>=20 >> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], = the SIOP will not return an access token to the RP". >>=20 >> An Identity Wallet is not an AS.=20 >>=20 >>>=20 >>> Roles:=20 >>> -> grant endpoint of the AS: Why is this a post request? This = eliminates the chance of having user device hosted AS (no server). >>> [FI] what would you propose instead? >>> Would also be interested to understand better the deployment model = when there is no server. That's something that was discussed several = times but I'm still missing the underlying architecture and use case. >>> [FP] See above (SIOP). There will be a lot of identity wallets = operated on end user device. >> See the above comment. Please, do not confuse an Identity Wallet with = an Authentication Server (AS). >>=20 >> Denis >>=20 >>>=20 >>> -> Resource Owner (RO) : Authorizes the request? Does it authorize = the request or the access to a resource? >>> [FI] yes, we should make the wording clearer >>>=20 >>> Missing Section Interactions: >>> --> This section shall introduce the notion of interaction before we = start listing interaction types. >>> [FI] yes=20 >>>=20 >>> Interaction Types: >>> --> I prefer a classification with Redirect, Decoupled and Embedded = is. In the draft, we have one redirect and 2 decouple interactions and = nothing else. >>> [FI] this should be handled as a specific discussion item. As a = reminder, how would you define embedded? >>>=20 >>> In practice there's at least these modes: >>> - redirect and redirect back >>> - redirect to different browser or device >>> - user code >>> - CIBA >>> [FP] This classification is limited. >>> Redirect: same device, same or different user agents (browser, = mobile app, desktop app, ...) >>> Decoupled: different devices >>> Embedded : RC carries RO authorization to AS >>>=20 >>>=20 >>> Resource Access Request vs. Resource Request >>> --> Both are mixed up. No clarification of the context of each = section. >>> [FI] could you clarify what you'd expect. Btw on this topic, = there's a more general discussion on whether we should make a = distinction or not.=20 >>> =E2=80=8B[FP]: Here: >>> Resource Access Request: Requesting Access to a resource. Response = is an access token (or any type of grant) >>> Resource Request: Request the resource. Response is the resource (or = a corresponding execution) >>>=20 >>> Token Content Negotiation >>> --> Not expressed as such. This is central to GNAP and not = represented enough in the document. >>> [FI] right. This should be a specific discussion item.=20 >>>=20 >>> Requesting "User" Information >>> we identify two types of users: RQ and RO. It will be better not to = refer to a user in this draft, but either to a RQ or an RO. >>> [FI] yes that would avoid potential misunderstandings. Although in = the end, people will translate RQ into user or end-user most of the = time. Cf in definition, currently we have Requesting Party (RQ, aka = "user") >>>=20 >>>=20 >>> Interaction Again >>> -> For each interaction type, we will have to describe the protocol = flow and the nature and behavior of involved Roles (Parties), Elements, = Requests. >>> [FI] yes =20 >>>=20 >>> [FP] Will these and into tickets? >>>=20 >>> Best regards. >>> /Francis >>>=20 >>>=20 >>>=20 >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_76024558-1412-4ACE-89FD-FAD697C5AB41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 One = of the biggest drawbacks of the current app-centric approaches in OIDC = (self-issued OP, or SIOP) is that they depend on using the front channel = and browser redirects to pass everything, which is something that GNAP = is deliberately getting away from by starting in the back channel.

That said, once a = request is kicked off in GNAP, the interaction and fulfillment can = happen through any number of means. Part of the work that=E2=80=99s = being done with the =E2=80=9Cinteraction=E2=80=9D section is going to = help facilitate this, and I think that there are some other potential = branches here.

Token delivery is where things get extra weird though =E2=80=94= we are explicitly not delivering tokens in the front channel in the = core of GNAP, we=E2=80=99re using the response from the continuation = API. One idea (that isn=E2=80=99t particularly well thought out and = hasn=E2=80=99t been implemented at all) is to have an extension declare = an alternative response from the =E2=80=9Ccontinue=E2=80=9D section = that=E2=80=99s defined today, which points to the GNPA continuation API. = If an extension defines some alternative way to deliver tokens, that = could live alongside a continuation API and the client could indicate = support for it in its initial request.

In any event, alternative interaction = and delivery methods are important, and even if we aren=E2=80=99t going = to support every last one of them directly, the protocol design should = at least be aware of them.

 =E2=80=94 Justin

On Feb = 4, 2021, at 8:35 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Tom, 

Sure, any experience on that would be = greatly appreciated, we're calling for help here (the point being that I = suspect what they're doing is not trivial).

Fabien

On Thu, Feb = 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
I've had = such an app working for over a year. There are issues which are being = addressed by the browser Interaction team of oidc.

thx ..Tom (mobile)

On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi = Francis, 

I've = tried a few things with regards to using the AS on a phone, but it's = really quite complex. 

Making that run on a phone comes with = quite a bit of trouble. The most difficult part if that we'd need to use = a secure element, but just installing and hosting a http server securely = is not a standard setup at all. I suggest interested people step in to = work on this, as we already have a lot of work for the (more usual) = server case and already handle a privacy preserving = scheme. 

Please let us know what you think.

Cheers,
Fabien 

On Tue, Nov = 24, 2020 at 5:55 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,

I've thought a bit more to = what you said. I think I'll give it a try as a separate experiment (in = code, not in theory). Not that I would expect it to be included in GNAP, = but I kind of like the idea :-)

The direct impact for GNAP = would be to think about multiple ASs. 

Will let = you know. 

Fabien 


Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha = <fpo@adorsys.de> a =C3=A9crit :
It would be nice if the protocol was designed at many layers of = abstraction.

  • The first layer shall design abstract protocol flows, = without specification of the mode and mechanism of interaction.
  • The second layer can instantiate the first layer for = dedicated interaction. Here we can talk http, we can define interactions = that presume server based token generation, we can define interaction = that run on user device based token generation.
This is also the fundament of the structure I proposed = for the spec (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>; Dick Hardt <dick.hardt@gmail.com>; Tom Jones = <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer = <jricher@mit.edu>
Subject: Re: [GNAP] Review of = draft-ietf-gnap-core-protocol-00
 
Would make sense, but not so easy as we rely = heavily on HTTP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a = local sandbox on your phone, for your own AS), but it's really early = stage. This also poses another question that Denis has put forward, i.e. = how do we handle the multiple AS scenario (likely to occur then). 

Fabien 

On Wed, Nov 18, 2020 at 12:16 PM Francis = Pouatcha <fpo@adorsys.de> = wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that = subsumes that the "AS" is a "Server". Designing a new protocol, we = cannot afford this limitation.
  • I just mentioned SIOP = to show a known and closed example? Let us not focus on the device local = discovery scheme (like openid:) for now.
  • As = capability of holding private keys on user device evolves, server-based = issuing of token will be fading out giving way to device local = generation of token.
While designing GNAP, let us assume the AS-Role can be = exercised on a user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth = <txauth-bounces@ietf.org> = on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis = <denis.ietf@free.fr>; GNAP Mailing = List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of = draft-ietf-gnap-core-protocol-00
 
Got it. 

So web apps invoke a openid: deep link and hope there is = an app to handle the openid: scheme? ... and that it is the user's = wallet rather than some malware that has registered openid: on the = mobile device?

A native app can attempt to open a deep link associated = with an app, and will fail if the app is not there. If the app is there, = it will be opened, so this can't be used to silently test if an app is = present, but it does allow a native app to provide an alternative experience if an app is not present. I don't think this = works with custom schemes ... and I don't know how it could work from a = web app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but = perhaps they can be convinced to make openid: a managed scheme similar = to mailto:, tel:, sms:, facetime: ?

[1] https://developer.apple.com/documentation/xcode/allowing_apps_a= nd_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_= app


3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones = <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized = for SIOP to have good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt = <dick.hardt@gmail.com> = wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using = localhost:8765 to communicate with the wallet. Am I correct?

/Dick 
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones = <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case = the AS is not online all of the time, so it is really implicit flow and = the OIDC id-token comes from the siop device directly.
(whether this is front-channel or back channel is no = longer an interesting question.)
Now if an always-on AS is required, that is possible, = but probably beyond the scope of this effort and would require something = like an agent-in-the-sky (with diamonds).
here is the = link to the 9 min video   https://youtu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin = Richer <jricher@mit.edu> = wrote:
Ultimately, in most situations like these in the real = world, the hurdle isn=E2=80=99t technical compatibility so much as it is = trust compatibility. The RP (client) needs to have some incentive to = trust the assertions and identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The = hard question is less =E2=80=9Chow=E2=80=9D to do that (which SSI = answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80= =99t answer very well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to = support this =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got = the start of it more than OAuth2/OIDC have by allowing the bootstrap of = the process from a starting call: the interaction and continuation URIs = handed back by the AS don=E2=80=99t need to be the same URIs that the client starts = with, so just like SIOP the process can start in HTTP and potentially = move to other communication channels. A major difference is that we = aren=E2=80=99t dependent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel = messages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve= got an opportunity to more explicitly open up alternative communication = channels here, and that=E2=80=99s something I=E2=80=99d like to see = engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete = proposal as to how that would work over specific protocols, starting = with what we=E2=80=99ve got today. 

 =E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> = wrote:

Hi Denis, hi Francis, 

At some point integration with SSI (on the = authentication side) will probably occur, including amongst other = possibilities SIOP (since they work with OpenID a part of the work will = probably be made easier). 

That being said, Denis is right. It's not an AS. = Technically it's entirely possible to rely on a decentralized wallet = (for instance on your phone) and a centralized AS. I know of a few = studies on how to decentralize the AS itself (for instance https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-= 02).
Maybe it exists, but I'm still looking for real = scenarios (or even architectures) where an AS is deployed directly on a = phone, and under the sole authority of the RO, while being compatible = with the rest of the world. 

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
Hello  Francis,

See two comments in line.


B) Current Document

Roles description = shall not hold any assumption on the physical structure of the party = fulfilling the roles.
[FI] = not sure what you mean
 [FP] for example, we assume the AS is a server! In = most SSI based use cases, the AS will be running on the user device. See = SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, = data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile = v0.1. DIF Working Group Draft

At no place within = these two documents, it is possible to imagine that "the AS will be = running on the user device".

=46rom section 3 of the DIF Working Group Draft:

      "Unlike the OIDC Authorization = Code Flow as per [OIDC.Core], the SIOP will not return an access token = to the RP".

An Identity Wallet is not an AS.


Roles: 
-> grant endpoint of the AS: Why = is this a post request? This eliminates the chance of having user device = hosted AS (no server).
[FI] = what would you propose instead?
Would = also be interested to understand better the deployment model when there = is no server. That's something that was discussed several times but I'm = still missing the underlying architecture and use case.
 [FP] See above (SIOP). There will be a lot of identity = wallets operated on end user device.

See the above comment. Please, do not confuse = an Identity Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : = Authorizes the request? Does it authorize the request or the access to a = resource?
[FI] = yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce = the notion of interaction before we start listing interaction = types.
[FI] = yes 

Interaction Types:
--> I prefer a classification = with Redirect, Decoupled and Embedded is. In the draft, we have one = redirect and 2 decouple interactions and nothing else.
[FI] = this should be handled as a specific discussion item. As a reminder, how = would you define embedded?

In = practice there's at least these modes:
- = redirect and redirect back
- = redirect to different browser or device
- = user code
- = CIBA
[FP] This classification is = limited.
  • Redirect: same device, same or different user agents = (browser, mobile app, desktop app, ...)
  • Decoupled: = different devices
  • Embedded : RC carries RO = authorization to AS


Resource Access Request vs. = Resource Request
--> Both are mixed up. No = clarification of the context of each section.
[FI] = could you clarify what you'd expect.  Btw on this topic, there's a = more general discussion on whether we should make a distinction or = not. 
=E2=80=8B[FP]: = Here:
  • Resource Access Request: = Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request = the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This = is central to GNAP and not represented enough  in the = document.
[FI] = right. This should be a specific discussion item. 

Requesting "User" Information
we identify two types of users: RQ = and RO. It will be better not to refer to a user in this draft, but = either to a RQ or an RO.
[FI] = yes that would avoid potential misunderstandings. Although in the end, = people will translate RQ into user or end-user most of the time. Cf = in definition, currently we have Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we = will have to describe the protocol flow and the nature and behavior of = involved Roles (Parties), Elements, Requests.
[FI] = yes  

[FP] Will these and into tickets?

Best regards.
/Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

= --Apple-Mail=_76024558-1412-4ACE-89FD-FAD697C5AB41-- From nobody Thu Feb 4 07:48:00 2021 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 4F8543A1609 for ; Thu, 4 Feb 2021 07:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 o_wbN7hicQEo for ; Thu, 4 Feb 2021 07:47:48 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 BD9B73A15E3 for ; Thu, 4 Feb 2021 07:47:48 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id q9so3009427ilo.1 for ; Thu, 04 Feb 2021 07:47:48 -0800 (PST) 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=0m0j3QW+rmUjxji5NbARgCuAzT9vDCGDQC4GDOSSdHE=; b=OWBjudYJT9DtLfY87l+MGOhWBOaOEE/5/nRYPguFGarhxfxW3Z+zNAQiLM/ZRH7zGe REptXP8CLlcC+LZScIB1ctWrG1M1B1EN8X73i+ajJl5B8ZulaGX7di0pdb0u8Sp6uI5Y rdgBq4LCa7+XgYVWV+oqlf3cBMtXdq2GqJCKBPHUY7Xz2COrb39XOgHJMBIfUqgmdq3u UoTgs3mwXmVp4NhR9MbMX9iVtv/dEsJe8JK8nzDL0se0UXqfcnrXCXCGlsQFKbZ3/hLJ dL72EljVtfSsNl7kMLaql2GRiVYRm32eX5swOXZPrXU74bVQ4YWXj6we+6T7iG0czOYa VNNw== 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=0m0j3QW+rmUjxji5NbARgCuAzT9vDCGDQC4GDOSSdHE=; b=FQow8kc7UfRY8tgjdbqtWfKGj0jJfOV4BwmFVnUQi5FeexCgZmJtCh/6sRFRhSzI/u uu2voftHUBvA0U0uipJB/OVQzl9w/JLgwpQPlzkUEATfi8XvsqRDlkO0KThaDLCiblft 1RxhMexJFaky+R4O/+z3T0w+PZFvr9LSC1hjg06Kz6KUOHbcOnHtCRODOAyQYWqisnPD EqoU5Mam0CoQjp5HzVUMTb0EG7K1qoe/EWGgHvIxTV8NBuEHcadhGE/p8pEeHUIUuwjc bCC4zstwacqI7m2i8XcrjqgxpfXuaKMvefAGgnVDXZOVKE5qGgGzoiYo7elN/KGuTJBe rRDA== X-Gm-Message-State: AOAM531eOG0wcIIwvTt4UJzD7/cDe+w5VVGaVNRY1KnuN5danAui6aRh 2eEGY9X/nPXuqQLnVw0+fSlx+87kicEuoiIJ8mA= X-Google-Smtp-Source: ABdhPJwvQZspc3EVJVe4z52J9DTqbzELL9Aa45w5Fd2Am5EkOyZgRwEFiwQffeAWISwoBZCFtvvUywiEI+RyXYoZscE= X-Received: by 2002:a05:6e02:1cac:: with SMTP id x12mr6365080ill.188.1612453667911; Thu, 04 Feb 2021 07:47:47 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> In-Reply-To: <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> From: Fabien Imbault Date: Thu, 4 Feb 2021 16:47:34 +0100 Message-ID: To: Justin Richer Cc: Tom Jones , Francis Pouatcha , GNAP Mailing List , Dick Hardt , Denis Content-Type: multipart/alternative; boundary="00000000000017bee905ba84a024" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 15:47:59 -0000 --00000000000017bee905ba84a024 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, issue (#168) message based interaction / DIDComm is a tentative alternative mecanism for the interaction part. Not sure how that would work in details though, prototyping will probably help here. Token delivery through continuation seems fine to me. The client will probably have to wait for the next polling before it receives a token issued as the result of an asynchronous interaction, but that's not a big issue. But the AS on the phone seems like a harder nut to crack, at least at first sight. I think that would be awesome, but it gives me headaches, so I think I'll work on easier stuff right now ;-) Fabien On Thu, Feb 4, 2021 at 4:30 PM Justin Richer wrote: > One of the biggest drawbacks of the current app-centric approaches in OID= C > (self-issued OP, or SIOP) is that they depend on using the front channel > and browser redirects to pass everything, which is something that GNAP is > deliberately getting away from by starting in the back channel. > > That said, once a request is kicked off in GNAP, the interaction and > fulfillment can happen through any number of means. Part of the work that= =E2=80=99s > being done with the =E2=80=9Cinteraction=E2=80=9D section is going to hel= p facilitate this, > and I think that there are some other potential branches here. > > Token delivery is where things get extra weird though =E2=80=94 we are ex= plicitly > not delivering tokens in the front channel in the core of GNAP, we=E2=80= =99re using > the response from the continuation API. One idea (that isn=E2=80=99t part= icularly > well thought out and hasn=E2=80=99t been implemented at all) is to have a= n > extension declare an alternative response from the =E2=80=9Ccontinue=E2= =80=9D section > that=E2=80=99s defined today, which points to the GNPA continuation API. = If an > extension defines some alternative way to deliver tokens, that could live > alongside a continuation API and the client could indicate support for it > in its initial request. > > In any event, alternative interaction and delivery methods are important, > and even if we aren=E2=80=99t going to support every last one of them dir= ectly, the > protocol design should at least be aware of them. > > =E2=80=94 Justin > > On Feb 4, 2021, at 8:35 AM, Fabien Imbault > wrote: > > Hi Tom, > > Sure, any experience on that would be greatly appreciated, we're calling > for help here (the point being that I suspect what they're doing is not > trivial). > > Fabien > > On Thu, Feb 4, 2021 at 2:21 PM Tom Jones > wrote: > >> I've had such an app working for over a year. There are issues which are >> being addressed by the browser Interaction team of oidc. >> >> thx ..Tom (mobile) >> >> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault >> wrote: >> >>> Hi Francis, >>> >>> I've tried a few things with regards to using the AS on a phone, but >>> it's really quite complex. >>> >>> Making that run on a phone comes with quite a bit of trouble. The most >>> difficult part if that we'd need to use a secure element, but just >>> installing and hosting a http server securely is not a standard setup a= t >>> all. I suggest interested people step in to work on this, as we already >>> have a lot of work for the (more usual) server case and already handle = a >>> privacy preserving scheme. >>> >>> Please let us know what you think. >>> >>> Cheers, >>> Fabien >>> >>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault >>> wrote: >>> >>>> Hi Francis, >>>> >>>> I've thought a bit more to what you said. I think I'll give it a try a= s >>>> a separate experiment (in code, not in theory). Not that I would expec= t it >>>> to be included in GNAP, but I kind of like the idea :-) >>>> >>>> The direct impact for GNAP would be to think about multiple ASs. >>>> >>>> Will let you know. >>>> >>>> Fabien >>>> >>>> >>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha a >>>> =C3=A9crit : >>>> >>>>> It would be nice if the protocol was designed at many layers of >>>>> abstraction. >>>>> >>>>> >>>>> - The first layer shall design abstract protocol flows, without >>>>> specification of the mode and mechanism of interaction. >>>>> - The second layer can instantiate the first layer for dedicated >>>>> interaction. Here we can talk http, we can define interactions tha= t presume >>>>> server based token generation, we can define interaction that run = on user >>>>> device based token generation. >>>>> >>>>> This is also the fundament of the structure I proposed for the spec ( >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). >>>>> >>>>> /Francis >>>>> >>>>> ------------------------------ >>>>> *From:* Fabien Imbault >>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>>> *To:* Francis Pouatcha >>>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>>> dick.hardt@gmail.com>; Tom Jones ; >>>>> Denis ; Justin Richer >>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>> >>>>> Would make sense, but not so easy as we rely heavily on HTTP. Hence >>>>> the discussion about deep links and so on. >>>>> >>>>> An alternative might be provided by wasm/wasi (running a local sandbo= x >>>>> on your phone, for your own AS), but it's really early stage. This al= so >>>>> poses another question that Denis has put forward, i.e. how do we han= dle >>>>> the multiple AS scenario (likely to occur then). >>>>> >>>>> Fabien >>>>> >>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha >>>>> wrote: >>>>> >>>>> We are drifting away from the original problem space. >>>>> >>>>> - My original mention was about the "POST" request, that subsumes >>>>> that the "AS" is a "Server". Designing a new protocol, we cannot a= fford >>>>> this limitation. >>>>> - I just mentioned SIOP to show a known and closed example? Let us >>>>> not focus on the device local discovery scheme (like openid:) for = now. >>>>> - As capability of holding private keys on user device evolves, >>>>> server-based issuing of token will be fading out giving way to dev= ice local >>>>> generation of token. >>>>> >>>>> While designing GNAP, let us assume the AS-Role can be exercised on a >>>>> user device and design the protocol to honor that. >>>>> >>>>> Best regards, >>>>> /Francis >>>>> ------------------------------ >>>>> *From:* TXAuth on behalf of Dick Hardt < >>>>> dick.hardt@gmail.com> >>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>>> *To:* Tom Jones >>>>> *Cc:* Fabien Imbault ; Denis < >>>>> denis.ietf@free.fr>; GNAP Mailing List ; Justin >>>>> Richer >>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>> >>>>> Got it. >>>>> >>>>> So web apps invoke a openid: deep link and hope there is an app to >>>>> handle the openid: scheme? ... and that it is the user's wallet rathe= r than >>>>> some malware that has registered openid: on the mobile device? >>>>> >>>>> A native app can attempt to open a deep link associated with an app, >>>>> and will fail if the app is not there. If the app is there, it will b= e >>>>> opened, so this can't be used to silently test if an app is present, = but it >>>>> does allow a native app to provide an alternative experience if an ap= p is >>>>> not present. I don't think this works with custom schemes ... and I d= on't >>>>> know how it could work from a web app on the phone with the current S= afari >>>>> APIs. >>>>> >>>>> Apple warns against using custom schemes [1] ... but perhaps they can >>>>> be convinced to make openid: a managed scheme similar to mailto:, >>>>> tel:, sms:, facetime: ? >>>>> >>>>> [1] >>>>> https://developer.apple.com/documentation/xcode/allowing_apps_and_web= sites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app >>>>> >>>>> >>>>> =E1=90=A7 >>>>> >>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>>> thomasclinganjones@gmail.com> wrote: >>>>> >>>>> You are - that is not standard which is opeind:// >>>>> This is the one step that still needs to be optimized for SIOP to hav= e >>>>> good UX. >>>>> Peace ..tom >>>>> >>>>> >>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt >>>>> wrote: >>>>> >>>>> Hi Tom >>>>> >>>>> I watched your video (I watched at 2X speed) >>>>> >>>>> Looks like the employment website app that is using localhost:8765 to >>>>> communicate with the wallet. Am I correct? >>>>> >>>>> /Dick >>>>> =E1=90=A7 >>>>> >>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones < >>>>> thomasclinganjones@gmail.com> wrote: >>>>> >>>>> Well, here's a demo. Note that in this case the AS is not online all >>>>> of the time, so it is really implicit flow and the OIDC id-token come= s from >>>>> the siop device directly. >>>>> (whether this is front-channel or back channel is no longer an >>>>> interesting question.) >>>>> Now if an always-on AS is required, that is possible, but probably >>>>> beyond the scope of this effort and would require something like an >>>>> agent-in-the-sky (with diamonds). >>>>> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 >>>>> >>>>> Peace ..tom >>>>> >>>>> >>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote= : >>>>> >>>>> Ultimately, in most situations like these in the real world, the >>>>> hurdle isn=E2=80=99t technical compatibility so much as it is trust c= ompatibility. >>>>> The RP (client) needs to have some incentive to trust the assertions = and >>>>> identity information that=E2=80=99s coming from the AS. The same is t= rue for an RS >>>>> trusting tokens from the AS. The hard question is less =E2=80=9Chow= =E2=80=9D to do that >>>>> (which SSI answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which= SSI doesn=E2=80=99t answer >>>>> very well, because it=E2=80=99s a hard question). >>>>> >>>>> Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on >>>>> device=E2=80=9D element. We=E2=80=99ve got the start of it more than = OAuth2/OIDC have by >>>>> allowing the bootstrap of the process from a starting call: the inter= action >>>>> and continuation URIs handed back by the AS don=E2=80=99t need to be = the same URIs >>>>> that the client starts with, so just like SIOP the process can start = in >>>>> HTTP and potentially move to other communication channels. A major >>>>> difference is that we aren=E2=80=99t dependent on the assumption that= the user will >>>>> always be in a browser at some stage, and so the whole raft of >>>>> front-channel messages that SIOP relies on doesn=E2=80=99t fly. That = said, we=E2=80=99ve >>>>> got an opportunity to more explicitly open up alternative communicati= on >>>>> channels here, and that=E2=80=99s something I=E2=80=99d like to see e= ngineered, even if >>>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete proposa= l as to how that would >>>>> work over specific protocols, starting with what we=E2=80=99ve got to= day. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault >>>>> wrote: >>>>> >>>>> Hi Denis, hi Francis, >>>>> >>>>> At some point integration with SSI (on the authentication side) will >>>>> probably occur, including amongst other possibilities SIOP (since the= y work >>>>> with OpenID a part of the work will probably be made easier). >>>>> >>>>> That being said, Denis is right. It's not an AS. Technically it's >>>>> entirely possible to rely on a decentralized wallet (for instance on = your >>>>> phone) and a centralized AS. I know of a few studies on how to decent= ralize >>>>> the AS itself (for instance >>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >>>>> Maybe it exists, but I'm still looking for real scenarios (or even >>>>> architectures) where an AS is deployed directly on a phone, and under= the >>>>> sole authority of the RO, while being compatible with the rest of the >>>>> world. >>>>> >>>>> Cheers, >>>>> Fabien >>>>> >>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >>>>> >>>>> Hello Francis, >>>>> >>>>> See two comments in line. >>>>> >>>>> >>>>> B) Current Document >>>>> >>>>> Roles description shall not hold any assumption on the physical >>>>> structure of the party fulfilling the roles. >>>>> [FI] not sure what you mean >>>>> >>>>> [FP] for example, we assume the AS is a server! In most SSI based us= e >>>>> cases, the AS will be running on the user device. See SIOP ( >>>>> https://identity.foundation/did-siop/). >>>>> >>>>> I browsed through the two drafts, i.e. : >>>>> >>>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >>>>> model, and representations W3C Working Draft 08 November 2020 >>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF >>>>> Working Group Draft >>>>> >>>>> At no place within these two documents, it is possible to imagine tha= t >>>>> "the AS will be running on the user device". >>>>> >>>>> From section 3 of the DIF Working Group Draft: >>>>> >>>>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], th= e >>>>> SIOP will not return an access token to the RP". >>>>> >>>>> An Identity Wallet is not an AS. >>>>> >>>>> >>>>> Roles: >>>>> -> grant endpoint of the AS: Why is this a post request? This >>>>> eliminates the chance of having user device hosted AS (no server). >>>>> [FI] what would you propose instead? >>>>> Would also be interested to understand better the deployment model >>>>> when there is no server. That's something that was discussed several = times >>>>> but I'm still missing the underlying architecture and use case. >>>>> >>>>> [FP] See above (SIOP). There will be a lot of identity wallets >>>>> operated on end user device. >>>>> >>>>> See the above comment. Please, do not confuse an Identity Wallet with >>>>> an Authentication Server (AS). >>>>> >>>>> Denis >>>>> >>>>> >>>>> -> Resource Owner (RO) : Authorizes the request? Does it authorize th= e >>>>> request or the access to a resource? >>>>> [FI] yes, we should make the wording clearer >>>>> >>>>> Missing Section Interactions: >>>>> --> This section shall introduce the notion of interaction before we >>>>> start listing interaction types. >>>>> [FI] yes >>>>> >>>>> Interaction Types: >>>>> --> I prefer a classification with Redirect, Decoupled and Embedded >>>>> is. In the draft, we have one redirect and 2 decouple interactions an= d >>>>> nothing else. >>>>> [FI] this should be handled as a specific discussion item. As a >>>>> reminder, how would you define embedded? >>>>> >>>>> In practice there's at least these modes: >>>>> - redirect and redirect back >>>>> - redirect to different browser or device >>>>> - user code >>>>> - CIBA >>>>> >>>>> [FP] This classification is limited. >>>>> >>>>> - Redirect: same device, same or different user agents (browser, >>>>> mobile app, desktop app, ...) >>>>> - Decoupled: different devices >>>>> - Embedded : RC carries RO authorization to AS >>>>> >>>>> >>>>> >>>>> Resource Access Request vs. Resource Request >>>>> --> Both are mixed up. No clarification of the context of each sectio= n. >>>>> [FI] could you clarify what you'd expect. Btw on this topic, there's >>>>> a more general discussion on whether we should make a distinction or = not. >>>>> >>>>> =E2=80=8B[FP]: Here: >>>>> >>>>> - Resource Access Request: Requesting Access to a resource. >>>>> Response is an access token (or any type of grant) >>>>> - Resource Request: Request the resource. Response is the resource >>>>> (or a corresponding execution) >>>>> >>>>> >>>>> Token Content Negotiation >>>>> --> Not expressed as such. This is central to GNAP and not represente= d >>>>> enough in the document. >>>>> [FI] right. This should be a specific discussion item. >>>>> >>>>> Requesting "User" Information >>>>> we identify two types of users: RQ and RO. It will be better not to >>>>> refer to a user in this draft, but either to a RQ or an RO. >>>>> [FI] yes that would avoid potential misunderstandings. Although in th= e >>>>> end, people will translate RQ into user or end-user most of the time.= Cf in >>>>> definition, currently we have Requesting Party (RQ, aka "user") >>>>> >>>>> >>>>> Interaction Again >>>>> -> For each interaction type, we will have to describe the protocol >>>>> flow and the nature and behavior of involved Roles (Parties), Element= s, >>>>> Requests. >>>>> [FI] yes >>>>> >>>>> >>>>> [FP] Will these and into tickets? >>>>> >>>>> Best regards. >>>>> /Francis >>>>> >>>>> >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> > --00000000000017bee905ba84a024 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, issue (#168)=C2=A0message based interaction / DIDComm= is a tentative alternative mecanism for the interaction part. Not sure how= that would work in details=C2=A0though, prototyping will probably help her= e.
Token delivery=C2=A0through continuation seems fine to me. The clien= t will probably have to wait for the next polling before it receives a toke= n issued as the result of an asynchronous interaction, but that's not a= big issue.

But the AS on the phone seems like a h= arder nut to crack, at least at first sight. I think that would be awesome,= but it gives me headaches, so I think I'll work on easier stuff right = now ;-)

Fabien=C2=A0=C2=A0

On Thu, Feb 4,= 2021 at 4:30 PM Justin Richer <jrich= er@mit.edu> wrote:
One of the biggest dra= wbacks of the current app-centric approaches in OIDC (self-issued OP, or SI= OP) is that they depend on using the front channel and browser redirects to= pass everything, which is something that GNAP is deliberately getting away= from by starting in the back channel.

That said, once a= request is kicked off in GNAP, the interaction and fulfillment can happen = through any number of means. Part of the work that=E2=80=99s being done wit= h the =E2=80=9Cinteraction=E2=80=9D section is going to help facilitate thi= s, and I think that there are some other potential branches here.

Token delivery is where things get extra weird though =E2= =80=94 we are explicitly not delivering tokens in the front channel in the = core of GNAP, we=E2=80=99re using the response from the continuation API. O= ne idea (that isn=E2=80=99t particularly well thought out and hasn=E2=80=99= t been implemented at all) is to have an extension declare an alternative r= esponse from the =E2=80=9Ccontinue=E2=80=9D section that=E2=80=99s defined = today, which points to the GNPA continuation API. If an extension defines s= ome alternative way to deliver tokens, that could live alongside a continua= tion API and the client could indicate support for it in its initial reques= t.

In any event, alternative interaction and deliv= ery methods are important, and even if we aren=E2=80=99t going to support e= very last one of them directly, the protocol design should at least be awar= e of them.

=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 8:35 AM, Fabien Imbault <<= a href=3D"mailto:fabien.imbault@gmail.com" target=3D"_blank">fabien.imbault= @gmail.com> wrote:

Hi Tom,=C2=A0
=
Sure, any experience on that would be greatly appreciated, w= e're calling for help here (the point being that I suspect what they= 9;re doing is not trivial).

Fabien

=
On Thu, Fe= b 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
I&#= 39;ve had such an app working for over a year. There are issues which are b= eing addressed by the browser Interaction team of oidc.

thx ..T= om (mobile)

On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault <fabien.imbault@gmail.co= m> wrote:
Hi Francis,=C2=A0

I've tried a few= things with regards to using the AS on a phone, but it's really quite= =C2=A0complex.=C2=A0

Making that run on a phone co= mes with quite a bit of trouble. The most difficult part if that we'd n= eed to use a secure element, but just installing and hosting a http server = securely is not a standard setup at all. I suggest interested people step i= n to work on this, as we already have a lot of work for the (more usual) se= rver case and already handle a privacy preserving scheme.=C2=A0
<= br>
Please let us know what you think.

C= heers,
Fabien=C2=A0

On Tue, Nov 24, 2020 at 5:55 AM Fabien I= mbault <fabien.imbault@gmail.com> wrote:
Hi Francis,=

I've thought a bit more t= o what you said. I think I'll give it a try as a separate experiment (i= n code, not in theory). Not that I would expect it to be included in GNAP, = but I kind of like the idea :-)

The direct impact for GNAP would be to think about multiple ASs.= =C2=A0

Will let you know= .=C2=A0

Fabien=C2=A0

= Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha <fpo@adorsys.de> = a =C3=A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"gmail-m_-7520389457378808664gmail-m_-3342024782330569254m_8014700032835= 912204gmail-m_142651873244800559m_8348797445460806175LPlnk338391" rel=3D"no= referrer noreferrer" target=3D"_blank">https://github.com/ietf-wg-gnap/gnap= -core-protocol/issues/30).

/Francis
<= /div>

= From: Fabien Imbault <fabien.imbault@gmail.com&= gt;
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>;= Dick Hardt <dick.hardt@gmail.com>; Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-b= ounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com<= /a>>
Cc: Fabien Imbault <fabien.imbault@gmail.com= >; Denis <denis.ietf@free.fr>; GNAP Mailing List &l= t;txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://yo= utu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabi= en.imbault@gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentralized= -02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis= .ietf@free.fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundati= on/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= =E2=80=8B= [FP]: Here:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth

--00000000000017bee905ba84a024-- From nobody Thu Feb 4 10:03:56 2021 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 3845A3A111E for ; Thu, 4 Feb 2021 10:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 zwXwqgkHSL6r for ; Thu, 4 Feb 2021 10:03:51 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 61BCF3A0C67 for ; Thu, 4 Feb 2021 10:03:51 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id d1so4239228otl.13 for ; Thu, 04 Feb 2021 10:03:51 -0800 (PST) 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=cPJplgWrfmVC42Dd+7+COBGUFtvwfKTs2JuKXdAJ7pg=; b=ZsSbCQT4Nk2Wc/kpELRItH2G+MVzyE86UMDAjIxH50xhmKmOfiz4piVq5rCqZhljBu j6cAHWgYwF1zgxi4GsmCa1Iw5AIesGosL9+TZOZFaXlxeHR5OhY8uVfqjgvXvzsHtGMO cB/qIKtsFDc7bw5sH/cSSqvbkLFfcpYnKdB8+6wl4mgpDYiaASizlZqHHHo3PAdkN6vs GQ7Kde4pFrDD4Bc2Fp0tU4ey7V9EM/uqPzZTAO+mN3AqfkztZjbqYHwQMZ8DKQk+LV5O xxa66O/gmhPXgfShcvhzU4RYLufySKCWYqzNt89V8nCZvGScFxiNiFYq8BtY+Q5kF3YP fc2w== 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=cPJplgWrfmVC42Dd+7+COBGUFtvwfKTs2JuKXdAJ7pg=; b=prbQ/IsIO55M3wmzIvuon7onXNQhMPhxHI5gdK4cVd9tQXkAyojd0wTmk0EsKm0i2w 9B4jaqYDMsr7bMGEFLlUVckNJCPjll0c94KxxaWC9K7G1yxHTjjVbtWxiqOwFwzn1WFa a0R7Xxb1tJqe+y4wInw/CV8VNq1tGfXjPFhvrJipqaECGj25dudhr0hUZ2m7xtpNjV79 cuR+N7RnqaJBbIUMYlqoTxD8B1B1nxeUj96nm+05jXP8NE5yBVtN32kYnshcphyqUNWA rMU2qR4/e+2EZPQBCEZZko/0LkNJwSplxJ9ahWTdzt7/azyA20nxR56UsezM6FWlG1SJ oA4g== X-Gm-Message-State: AOAM531XVdx4yhkfwWkk/GFfbEwSPGRTbbtcuTU2e66dO/JNAyxGpUkB ulnMFrH0C5edcqfmEEgV87Vy7yjTrs6hvvZp11g= X-Google-Smtp-Source: ABdhPJy4GpWJe3rmnkxU3oyvOYSk6x53O1cY7NH5ejv8ZwdI2eQMGd9zn3+/r6Csi7BGfWFig03PkRll8dAw4HVUrBE= X-Received: by 2002:a9d:37c4:: with SMTP id x62mr444706otb.87.1612461830480; Thu, 04 Feb 2021 10:03:50 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> In-Reply-To: From: Tom Jones Date: Thu, 4 Feb 2021 10:03:38 -0800 Message-ID: To: Fabien Imbault Cc: Justin Richer , Francis Pouatcha , GNAP Mailing List , Dick Hardt , Denis Content-Type: multipart/alternative; boundary="0000000000009ea7f805ba8686d5" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 18:03:55 -0000 --0000000000009ea7f805ba8686d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin's analysis of use of the front channel is misleading. It could equally be argued that what i have done is installed an AS on the phone and the communications with it & the PR is back channel. Basically the point is that the old OIDC paradigms are no longer valid. Be the change you want to see in the world ..tom On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault wrote: > Yes, issue (#168) message based interaction / DIDComm is a tentative > alternative mecanism for the interaction part. Not sure how that would wo= rk > in details though, prototyping will probably help here. > Token delivery through continuation seems fine to me. The client will > probably have to wait for the next polling before it receives a token > issued as the result of an asynchronous interaction, but that's not a big > issue. > > But the AS on the phone seems like a harder nut to crack, at least at > first sight. I think that would be awesome, but it gives me headaches, so= I > think I'll work on easier stuff right now ;-) > > Fabien > > On Thu, Feb 4, 2021 at 4:30 PM Justin Richer wrote: > >> One of the biggest drawbacks of the current app-centric approaches in >> OIDC (self-issued OP, or SIOP) is that they depend on using the front >> channel and browser redirects to pass everything, which is something tha= t >> GNAP is deliberately getting away from by starting in the back channel. >> >> That said, once a request is kicked off in GNAP, the interaction and >> fulfillment can happen through any number of means. Part of the work tha= t=E2=80=99s >> being done with the =E2=80=9Cinteraction=E2=80=9D section is going to he= lp facilitate this, >> and I think that there are some other potential branches here. >> >> Token delivery is where things get extra weird though =E2=80=94 we are e= xplicitly >> not delivering tokens in the front channel in the core of GNAP, we=E2=80= =99re using >> the response from the continuation API. One idea (that isn=E2=80=99t par= ticularly >> well thought out and hasn=E2=80=99t been implemented at all) is to have = an >> extension declare an alternative response from the =E2=80=9Ccontinue=E2= =80=9D section >> that=E2=80=99s defined today, which points to the GNPA continuation API.= If an >> extension defines some alternative way to deliver tokens, that could liv= e >> alongside a continuation API and the client could indicate support for i= t >> in its initial request. >> >> In any event, alternative interaction and delivery methods are important= , >> and even if we aren=E2=80=99t going to support every last one of them di= rectly, the >> protocol design should at least be aware of them. >> >> =E2=80=94 Justin >> >> On Feb 4, 2021, at 8:35 AM, Fabien Imbault >> wrote: >> >> Hi Tom, >> >> Sure, any experience on that would be greatly appreciated, we're calling >> for help here (the point being that I suspect what they're doing is not >> trivial). >> >> Fabien >> >> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones >> wrote: >> >>> I've had such an app working for over a year. There are issues which ar= e >>> being addressed by the browser Interaction team of oidc. >>> >>> thx ..Tom (mobile) >>> >>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault >>> wrote: >>> >>>> Hi Francis, >>>> >>>> I've tried a few things with regards to using the AS on a phone, but >>>> it's really quite complex. >>>> >>>> Making that run on a phone comes with quite a bit of trouble. The most >>>> difficult part if that we'd need to use a secure element, but just >>>> installing and hosting a http server securely is not a standard setup = at >>>> all. I suggest interested people step in to work on this, as we alread= y >>>> have a lot of work for the (more usual) server case and already handle= a >>>> privacy preserving scheme. >>>> >>>> Please let us know what you think. >>>> >>>> Cheers, >>>> Fabien >>>> >>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Francis, >>>>> >>>>> I've thought a bit more to what you said. I think I'll give it a try >>>>> as a separate experiment (in code, not in theory). Not that I would e= xpect >>>>> it to be included in GNAP, but I kind of like the idea :-) >>>>> >>>>> The direct impact for GNAP would be to think about multiple ASs. >>>>> >>>>> Will let you know. >>>>> >>>>> Fabien >>>>> >>>>> >>>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha = a >>>>> =C3=A9crit : >>>>> >>>>>> It would be nice if the protocol was designed at many layers of >>>>>> abstraction. >>>>>> >>>>>> >>>>>> - The first layer shall design abstract protocol flows, without >>>>>> specification of the mode and mechanism of interaction. >>>>>> - The second layer can instantiate the first layer for dedicated >>>>>> interaction. Here we can talk http, we can define interactions th= at presume >>>>>> server based token generation, we can define interaction that run= on user >>>>>> device based token generation. >>>>>> >>>>>> This is also the fundament of the structure I proposed for the spec = ( >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). >>>>>> >>>>>> /Francis >>>>>> >>>>>> ------------------------------ >>>>>> *From:* Fabien Imbault >>>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>>>> *To:* Francis Pouatcha >>>>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>>>> dick.hardt@gmail.com>; Tom Jones ; >>>>>> Denis ; Justin Richer >>>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>>> >>>>>> Would make sense, but not so easy as we rely heavily on HTTP. Hence >>>>>> the discussion about deep links and so on. >>>>>> >>>>>> An alternative might be provided by wasm/wasi (running a local >>>>>> sandbox on your phone, for your own AS), but it's really early stage= . This >>>>>> also poses another question that Denis has put forward, i.e. how do = we >>>>>> handle the multiple AS scenario (likely to occur then). >>>>>> >>>>>> Fabien >>>>>> >>>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha >>>>>> wrote: >>>>>> >>>>>> We are drifting away from the original problem space. >>>>>> >>>>>> - My original mention was about the "POST" request, that subsumes >>>>>> that the "AS" is a "Server". Designing a new protocol, we cannot = afford >>>>>> this limitation. >>>>>> - I just mentioned SIOP to show a known and closed example? Let >>>>>> us not focus on the device local discovery scheme (like openid:) = for now. >>>>>> - As capability of holding private keys on user device evolves, >>>>>> server-based issuing of token will be fading out giving way to de= vice local >>>>>> generation of token. >>>>>> >>>>>> While designing GNAP, let us assume the AS-Role can be exercised on = a >>>>>> user device and design the protocol to honor that. >>>>>> >>>>>> Best regards, >>>>>> /Francis >>>>>> ------------------------------ >>>>>> *From:* TXAuth on behalf of Dick Hardt < >>>>>> dick.hardt@gmail.com> >>>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>>>> *To:* Tom Jones >>>>>> *Cc:* Fabien Imbault ; Denis < >>>>>> denis.ietf@free.fr>; GNAP Mailing List ; Justin >>>>>> Richer >>>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>>> >>>>>> Got it. >>>>>> >>>>>> So web apps invoke a openid: deep link and hope there is an app to >>>>>> handle the openid: scheme? ... and that it is the user's wallet rath= er than >>>>>> some malware that has registered openid: on the mobile device? >>>>>> >>>>>> A native app can attempt to open a deep link associated with an app, >>>>>> and will fail if the app is not there. If the app is there, it will = be >>>>>> opened, so this can't be used to silently test if an app is present,= but it >>>>>> does allow a native app to provide an alternative experience if an a= pp is >>>>>> not present. I don't think this works with custom schemes ... and I = don't >>>>>> know how it could work from a web app on the phone with the current = Safari >>>>>> APIs. >>>>>> >>>>>> Apple warns against using custom schemes [1] ... but perhaps they ca= n >>>>>> be convinced to make openid: a managed scheme similar to mailto:, >>>>>> tel:, sms:, facetime: ? >>>>>> >>>>>> [1] >>>>>> https://developer.apple.com/documentation/xcode/allowing_apps_and_we= bsites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app >>>>>> >>>>>> >>>>>> =E1=90=A7 >>>>>> >>>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>>>> thomasclinganjones@gmail.com> wrote: >>>>>> >>>>>> You are - that is not standard which is opeind:// >>>>>> This is the one step that still needs to be optimized for SIOP to >>>>>> have good UX. >>>>>> Peace ..tom >>>>>> >>>>>> >>>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt >>>>>> wrote: >>>>>> >>>>>> Hi Tom >>>>>> >>>>>> I watched your video (I watched at 2X speed) >>>>>> >>>>>> Looks like the employment website app that is using localhost:8765 t= o >>>>>> communicate with the wallet. Am I correct? >>>>>> >>>>>> /Dick >>>>>> =E1=90=A7 >>>>>> >>>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones < >>>>>> thomasclinganjones@gmail.com> wrote: >>>>>> >>>>>> Well, here's a demo. Note that in this case the AS is not online all >>>>>> of the time, so it is really implicit flow and the OIDC id-token com= es from >>>>>> the siop device directly. >>>>>> (whether this is front-channel or back channel is no longer an >>>>>> interesting question.) >>>>>> Now if an always-on AS is required, that is possible, but probably >>>>>> beyond the scope of this effort and would require something like an >>>>>> agent-in-the-sky (with diamonds). >>>>>> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 >>>>>> >>>>>> Peace ..tom >>>>>> >>>>>> >>>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer >>>>>> wrote: >>>>>> >>>>>> Ultimately, in most situations like these in the real world, the >>>>>> hurdle isn=E2=80=99t technical compatibility so much as it is trust = compatibility. >>>>>> The RP (client) needs to have some incentive to trust the assertions= and >>>>>> identity information that=E2=80=99s coming from the AS. The same is = true for an RS >>>>>> trusting tokens from the AS. The hard question is less =E2=80=9Chow= =E2=80=9D to do that >>>>>> (which SSI answers), but more =E2=80=9Cwhy=E2=80=9D to do that (whic= h SSI doesn=E2=80=99t answer >>>>>> very well, because it=E2=80=99s a hard question). >>>>>> >>>>>> Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on >>>>>> device=E2=80=9D element. We=E2=80=99ve got the start of it more than= OAuth2/OIDC have by >>>>>> allowing the bootstrap of the process from a starting call: the inte= raction >>>>>> and continuation URIs handed back by the AS don=E2=80=99t need to be= the same URIs >>>>>> that the client starts with, so just like SIOP the process can start= in >>>>>> HTTP and potentially move to other communication channels. A major >>>>>> difference is that we aren=E2=80=99t dependent on the assumption tha= t the user will >>>>>> always be in a browser at some stage, and so the whole raft of >>>>>> front-channel messages that SIOP relies on doesn=E2=80=99t fly. That= said, we=E2=80=99ve >>>>>> got an opportunity to more explicitly open up alternative communicat= ion >>>>>> channels here, and that=E2=80=99s something I=E2=80=99d like to see = engineered, even if >>>>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete propos= al as to how that would >>>>>> work over specific protocols, starting with what we=E2=80=99ve got t= oday. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>> Hi Denis, hi Francis, >>>>>> >>>>>> At some point integration with SSI (on the authentication side) will >>>>>> probably occur, including amongst other possibilities SIOP (since th= ey work >>>>>> with OpenID a part of the work will probably be made easier). >>>>>> >>>>>> That being said, Denis is right. It's not an AS. Technically it's >>>>>> entirely possible to rely on a decentralized wallet (for instance on= your >>>>>> phone) and a centralized AS. I know of a few studies on how to decen= tralize >>>>>> the AS itself (for instance >>>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >>>>>> Maybe it exists, but I'm still looking for real scenarios (or even >>>>>> architectures) where an AS is deployed directly on a phone, and unde= r the >>>>>> sole authority of the RO, while being compatible with the rest of th= e >>>>>> world. >>>>>> >>>>>> Cheers, >>>>>> Fabien >>>>>> >>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >>>>>> >>>>>> Hello Francis, >>>>>> >>>>>> See two comments in line. >>>>>> >>>>>> >>>>>> B) Current Document >>>>>> >>>>>> Roles description shall not hold any assumption on the physical >>>>>> structure of the party fulfilling the roles. >>>>>> [FI] not sure what you mean >>>>>> >>>>>> [FP] for example, we assume the AS is a server! In most SSI based >>>>>> use cases, the AS will be running on the user device. See SIOP ( >>>>>> https://identity.foundation/did-siop/). >>>>>> >>>>>> I browsed through the two drafts, i.e. : >>>>>> >>>>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >>>>>> model, and representations W3C Working Draft 08 November 2020 >>>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF >>>>>> Working Group Draft >>>>>> >>>>>> At no place within these two documents, it is possible to imagine >>>>>> that "the AS will be running on the user device". >>>>>> >>>>>> From section 3 of the DIF Working Group Draft: >>>>>> >>>>>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], >>>>>> the SIOP will not return an access token to the RP". >>>>>> >>>>>> An Identity Wallet is not an AS. >>>>>> >>>>>> >>>>>> Roles: >>>>>> -> grant endpoint of the AS: Why is this a post request? This >>>>>> eliminates the chance of having user device hosted AS (no server). >>>>>> [FI] what would you propose instead? >>>>>> Would also be interested to understand better the deployment model >>>>>> when there is no server. That's something that was discussed several= times >>>>>> but I'm still missing the underlying architecture and use case. >>>>>> >>>>>> [FP] See above (SIOP). There will be a lot of identity wallets >>>>>> operated on end user device. >>>>>> >>>>>> See the above comment. Please, do not confuse an Identity Wallet wit= h >>>>>> an Authentication Server (AS). >>>>>> >>>>>> Denis >>>>>> >>>>>> >>>>>> -> Resource Owner (RO) : Authorizes the request? Does it authorize >>>>>> the request or the access to a resource? >>>>>> [FI] yes, we should make the wording clearer >>>>>> >>>>>> Missing Section Interactions: >>>>>> --> This section shall introduce the notion of interaction before we >>>>>> start listing interaction types. >>>>>> [FI] yes >>>>>> >>>>>> Interaction Types: >>>>>> --> I prefer a classification with Redirect, Decoupled and Embedded >>>>>> is. In the draft, we have one redirect and 2 decouple interactions a= nd >>>>>> nothing else. >>>>>> [FI] this should be handled as a specific discussion item. As a >>>>>> reminder, how would you define embedded? >>>>>> >>>>>> In practice there's at least these modes: >>>>>> - redirect and redirect back >>>>>> - redirect to different browser or device >>>>>> - user code >>>>>> - CIBA >>>>>> >>>>>> [FP] This classification is limited. >>>>>> >>>>>> - Redirect: same device, same or different user agents (browser, >>>>>> mobile app, desktop app, ...) >>>>>> - Decoupled: different devices >>>>>> - Embedded : RC carries RO authorization to AS >>>>>> >>>>>> >>>>>> >>>>>> Resource Access Request vs. Resource Request >>>>>> --> Both are mixed up. No clarification of the context of each >>>>>> section. >>>>>> [FI] could you clarify what you'd expect. Btw on this topic, there'= s >>>>>> a more general discussion on whether we should make a distinction or= not. >>>>>> >>>>>> =E2=80=8B[FP]: Here: >>>>>> >>>>>> - Resource Access Request: Requesting Access to a resource. >>>>>> Response is an access token (or any type of grant) >>>>>> - Resource Request: Request the resource. Response is the >>>>>> resource (or a corresponding execution) >>>>>> >>>>>> >>>>>> Token Content Negotiation >>>>>> --> Not expressed as such. This is central to GNAP and not >>>>>> represented enough in the document. >>>>>> [FI] right. This should be a specific discussion item. >>>>>> >>>>>> Requesting "User" Information >>>>>> we identify two types of users: RQ and RO. It will be better not to >>>>>> refer to a user in this draft, but either to a RQ or an RO. >>>>>> [FI] yes that would avoid potential misunderstandings. Although in >>>>>> the end, people will translate RQ into user or end-user most of the = time. >>>>>> Cf in definition, currently we have Requesting Party (RQ, aka "user"= ) >>>>>> >>>>>> >>>>>> Interaction Again >>>>>> -> For each interaction type, we will have to describe the protocol >>>>>> flow and the nature and behavior of involved Roles (Parties), Elemen= ts, >>>>>> Requests. >>>>>> [FI] yes >>>>>> >>>>>> >>>>>> [FP] Will these and into tickets? >>>>>> >>>>>> Best regards. >>>>>> /Francis >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >> --0000000000009ea7f805ba8686d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Justin's analysis of use of the front channel is misle= ading.
It could equally be argued that what i have done is installed an= AS on the phone and the communications with it & the PR is back channe= l.
Basically the point is that the old OIDC paradigms are no long= er valid.
Be the change you want to se= e in the world ..tom


On Thu, Feb 4,= 2021 at 7:47 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Yes, issue (#168)=C2=A0messag= e based interaction / DIDComm is a tentative alternative mecanism for the i= nteraction part. Not sure how that would work in details=C2=A0though, proto= typing will probably help here.
Token delivery=C2=A0through continuatio= n seems fine to me. The client will probably have to wait for the next poll= ing before it receives a token issued as the result of an asynchronous inte= raction, but that's not a big issue.

But the A= S on the phone seems like a harder nut to crack, at least at first sight. I= think that would be awesome, but it gives me headaches, so I think I'l= l work on easier stuff right now ;-)

Fabien=C2=A0= =C2=A0

On Thu, Feb 4, 2021 at 4:30 PM Justin Richer <jricher@mit.edu> wrote:
One of the b= iggest drawbacks of the current app-centric approaches in OIDC (self-issued= OP, or SIOP) is that they depend on using the front channel and browser re= directs to pass everything, which is something that GNAP is deliberately ge= tting away from by starting in the back channel.

That sa= id, once a request is kicked off in GNAP, the interaction and fulfillment c= an happen through any number of means. Part of the work that=E2=80=99s bein= g done with the =E2=80=9Cinteraction=E2=80=9D section is going to help faci= litate this, and I think that there are some other potential branches here.=

Token delivery is where things get extra weird th= ough =E2=80=94 we are explicitly not delivering tokens in the front channel= in the core of GNAP, we=E2=80=99re using the response from the continuatio= n API. One idea (that isn=E2=80=99t particularly well thought out and hasn= =E2=80=99t been implemented at all) is to have an extension declare an alte= rnative response from the =E2=80=9Ccontinue=E2=80=9D section that=E2=80=99s= defined today, which points to the GNPA continuation API. If an extension = defines some alternative way to deliver tokens, that could live alongside a= continuation API and the client could indicate support for it in its initi= al request.

In any event, alternative interaction = and delivery methods are important, and even if we aren=E2=80=99t going to = support every last one of them directly, the protocol design should at leas= t be aware of them.

=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 8:35 AM, Fabien Imba= ult <fabie= n.imbault@gmail.com> wrote:

Hi Tom,= =C2=A0

Sure, any experience on that would be greatly app= reciated, we're calling for help here (the point being that I suspect w= hat they're doing is not trivial).

Fabien

On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com> w= rote:
I've had such an app working for over a year. There are issue= s which are being addressed by the browser Interaction team of oidc.
thx ..Tom (mobile)

On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault &= lt;fabien.imb= ault@gmail.com> wrote:
Hi Francis,=C2=A0

I'v= e tried a few things with regards to using the AS on a phone, but it's = really quite=C2=A0complex.=C2=A0

Making that run o= n a phone comes with quite a bit of trouble. The most difficult part if tha= t we'd need to use a secure element, but just installing and hosting a = http server securely is not a standard setup at all. I suggest interested p= eople step in to work on this, as we already have a lot of work for the (mo= re usual) server case and already handle a privacy preserving scheme.=C2=A0=

Please let us know what you think.

=
Cheers,
Fabien=C2=A0

On Tue, Nov 24, 2020 at 5:55= AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,

I've thought = a bit more to what you said. I think I'll give it a try as a separate e= xperiment (in code, not in theory). Not that I would expect it to be includ= ed in GNAP, but I kind of like the idea :-)

The direct impact for GNAP would be to think about mult= iple ASs.=C2=A0

Will let= you know.=C2=A0

Fabien= =C2=A0


Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha <fpo@adorsys= .de> a =C3=A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"gmail-m_-3037161202240578685gmail-m_-7520389457378808664gmail-m_-334202= 4782330569254m_8014700032835912204gmail-m_142651873244800559m_8348797445460= 806175LPlnk338391" rel=3D"noreferrer noreferrer" target=3D"_blank">https://= github.com/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <f= abien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>;= Dick Hardt <dick.hardt@gmail.com>; Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth = <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com<= /a>>
Cc: Fabien Imbault <fabien.imbault@gmail.com= >; Denis <denis.ietf@free.fr>; GNAP Mailing List &l= t;txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://yo= utu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabi= en.imbault@gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentralized= -02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis= .ietf@free.fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundati= on/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= =E2=80=8B= [FP]: Here:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth

--0000000000009ea7f805ba8686d5-- From nobody Thu Feb 4 10:07:36 2021 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 F31F73A16E3 for ; Thu, 4 Feb 2021 10:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 FTb1HO18S6lD for ; Thu, 4 Feb 2021 10:07:31 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 D7ABB3A16E5 for ; Thu, 4 Feb 2021 10:07:30 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id j5so4158505iog.11 for ; Thu, 04 Feb 2021 10:07:30 -0800 (PST) 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=KVZU41gLWYtkIkeXFtGKlpju+HaxLM/hKM1tiflyPEc=; b=YDW1nFelWzc4TjGPlXYkyvLiSs7x7OVDAueSp8cQBAL41Nw5I/IAHWOJ16tCXQ3Cnx T4v1vgFduq9Fxny6hSMW9DNg+DBR92IIs3kwZO50g7P/g42jZH5paNKIvcv7XscI46xl gO/MZwm9mstaGATyoE/MZAJCMB9pF7PWVtTQxjG6m0PF+BAOUB8rHKPuQAqfkvdhdj7A IQF7UXdRu1DtXyMd5N0oUfU2PnoMUlr8wbsgBx+eVQEfqPOrM3xdYhK+FTu5NemKU677 jIjUBJiA0iPENh8Wqp5xpug6SzzIV43fhPM4alVrvM91VMSzxgnXzc9ng7gmYgxKU1SX MDUw== 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=KVZU41gLWYtkIkeXFtGKlpju+HaxLM/hKM1tiflyPEc=; b=B3tp/hxZausQqI+LNMFAd/I+Nd4VN402WK94gFOUX/yUMP18fhrieDMi4unmqXSMcS xqbhwscOa9hKEvrt0btHPN3qg7wjGiMiyHtki80Xr9TA2Dou1JFjDmP9NHegZatT6KtV OoHH/RjZC4AcLs9nnm1j14L64+s5cY7H8RrIJJeq+wdDRVuOVVfwbDQRB0F3nNAA/jXI iQgnYuxarq6sKbygWVb7Ix4a/ExG9CY5clnjJHMXdcfgvVq1ME1wuTu6QSWmaw2jCbt7 4hLw+kZQW9Bdfpowrg8LPemuAN6PRt5q/Kz47n/AHolQCDhtXofmxwMLFeGIP9wCmf75 Q5yQ== X-Gm-Message-State: AOAM533fT2OI6e6XpYtdJFHfZO10G6dSLtVLr2fDqaV9xxtyJEoqL9wD lAbPZrxP2HRszpVx37n7su725N9+3jiNDfyMC58= X-Google-Smtp-Source: ABdhPJwUn8lfSI2W0eqZosPz9BvG61dQdHqy3LnEvsFoh/8r3vSv95HnDfl0+H7Ol8Dz/Y3bhwUv5siirm8vI7fGTBk= X-Received: by 2002:a05:6638:33aa:: with SMTP id h42mr753679jav.124.1612462048673; Thu, 04 Feb 2021 10:07:28 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> In-Reply-To: From: Fabien Imbault Date: Thu, 4 Feb 2021 19:07:14 +0100 Message-ID: To: Tom Jones Cc: Justin Richer , Francis Pouatcha , GNAP Mailing List , Dick Hardt , Denis Content-Type: multipart/alternative; boundary="000000000000a004b905ba869348" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 18:07:35 -0000 --000000000000a004b905ba869348 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok, to be enablers of change, we'd need to specify how this would work in detail. Again I find the objective attractive, it's just there a few technical hurdles along the way. HTTP has never been designed for this use case. On Thu, Feb 4, 2021 at 7:03 PM Tom Jones wrote: > Justin's analysis of use of the front channel is misleading. > It could equally be argued that what i have done is installed an AS on th= e > phone and the communications with it & the PR is back channel. > Basically the point is that the old OIDC paradigms are no longer valid. > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault > wrote: > >> Yes, issue (#168) message based interaction / DIDComm is a tentative >> alternative mecanism for the interaction part. Not sure how that would w= ork >> in details though, prototyping will probably help here. >> Token delivery through continuation seems fine to me. The client will >> probably have to wait for the next polling before it receives a token >> issued as the result of an asynchronous interaction, but that's not a bi= g >> issue. >> >> But the AS on the phone seems like a harder nut to crack, at least at >> first sight. I think that would be awesome, but it gives me headaches, s= o I >> think I'll work on easier stuff right now ;-) >> >> Fabien >> >> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer wrote: >> >>> One of the biggest drawbacks of the current app-centric approaches in >>> OIDC (self-issued OP, or SIOP) is that they depend on using the front >>> channel and browser redirects to pass everything, which is something th= at >>> GNAP is deliberately getting away from by starting in the back channel. >>> >>> That said, once a request is kicked off in GNAP, the interaction and >>> fulfillment can happen through any number of means. Part of the work th= at=E2=80=99s >>> being done with the =E2=80=9Cinteraction=E2=80=9D section is going to h= elp facilitate this, >>> and I think that there are some other potential branches here. >>> >>> Token delivery is where things get extra weird though =E2=80=94 we are >>> explicitly not delivering tokens in the front channel in the core of GN= AP, >>> we=E2=80=99re using the response from the continuation API. One idea (t= hat isn=E2=80=99t >>> particularly well thought out and hasn=E2=80=99t been implemented at al= l) is to >>> have an extension declare an alternative response from the =E2=80=9Ccon= tinue=E2=80=9D >>> section that=E2=80=99s defined today, which points to the GNPA continua= tion API. If >>> an extension defines some alternative way to deliver tokens, that could >>> live alongside a continuation API and the client could indicate support= for >>> it in its initial request. >>> >>> In any event, alternative interaction and delivery methods are >>> important, and even if we aren=E2=80=99t going to support every last on= e of them >>> directly, the protocol design should at least be aware of them. >>> >>> =E2=80=94 Justin >>> >>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault >>> wrote: >>> >>> Hi Tom, >>> >>> Sure, any experience on that would be greatly appreciated, we're callin= g >>> for help here (the point being that I suspect what they're doing is not >>> trivial). >>> >>> Fabien >>> >>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones >>> wrote: >>> >>>> I've had such an app working for over a year. There are issues which >>>> are being addressed by the browser Interaction team of oidc. >>>> >>>> thx ..Tom (mobile) >>>> >>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault >>>> wrote: >>>> >>>>> Hi Francis, >>>>> >>>>> I've tried a few things with regards to using the AS on a phone, but >>>>> it's really quite complex. >>>>> >>>>> Making that run on a phone comes with quite a bit of trouble. The mos= t >>>>> difficult part if that we'd need to use a secure element, but just >>>>> installing and hosting a http server securely is not a standard setup= at >>>>> all. I suggest interested people step in to work on this, as we alrea= dy >>>>> have a lot of work for the (more usual) server case and already handl= e a >>>>> privacy preserving scheme. >>>>> >>>>> Please let us know what you think. >>>>> >>>>> Cheers, >>>>> Fabien >>>>> >>>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Francis, >>>>>> >>>>>> I've thought a bit more to what you said. I think I'll give it a try >>>>>> as a separate experiment (in code, not in theory). Not that I would = expect >>>>>> it to be included in GNAP, but I kind of like the idea :-) >>>>>> >>>>>> The direct impact for GNAP would be to think about multiple ASs. >>>>>> >>>>>> Will let you know. >>>>>> >>>>>> Fabien >>>>>> >>>>>> >>>>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha = a >>>>>> =C3=A9crit : >>>>>> >>>>>>> It would be nice if the protocol was designed at many layers of >>>>>>> abstraction. >>>>>>> >>>>>>> >>>>>>> - The first layer shall design abstract protocol flows, without >>>>>>> specification of the mode and mechanism of interaction. >>>>>>> - The second layer can instantiate the first layer for dedicated >>>>>>> interaction. Here we can talk http, we can define interactions t= hat presume >>>>>>> server based token generation, we can define interaction that ru= n on user >>>>>>> device based token generation. >>>>>>> >>>>>>> This is also the fundament of the structure I proposed for the spec= ( >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). >>>>>>> >>>>>>> /Francis >>>>>>> >>>>>>> ------------------------------ >>>>>>> *From:* Fabien Imbault >>>>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>>>>> *To:* Francis Pouatcha >>>>>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>>>>> dick.hardt@gmail.com>; Tom Jones ; >>>>>>> Denis ; Justin Richer >>>>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>>>> >>>>>>> Would make sense, but not so easy as we rely heavily on HTTP. Hence >>>>>>> the discussion about deep links and so on. >>>>>>> >>>>>>> An alternative might be provided by wasm/wasi (running a local >>>>>>> sandbox on your phone, for your own AS), but it's really early stag= e. This >>>>>>> also poses another question that Denis has put forward, i.e. how do= we >>>>>>> handle the multiple AS scenario (likely to occur then). >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha >>>>>>> wrote: >>>>>>> >>>>>>> We are drifting away from the original problem space. >>>>>>> >>>>>>> - My original mention was about the "POST" request, that >>>>>>> subsumes that the "AS" is a "Server". Designing a new protocol, = we cannot >>>>>>> afford this limitation. >>>>>>> - I just mentioned SIOP to show a known and closed example? Let >>>>>>> us not focus on the device local discovery scheme (like openid:)= for now. >>>>>>> - As capability of holding private keys on user device evolves, >>>>>>> server-based issuing of token will be fading out giving way to d= evice local >>>>>>> generation of token. >>>>>>> >>>>>>> While designing GNAP, let us assume the AS-Role can be exercised on >>>>>>> a user device and design the protocol to honor that. >>>>>>> >>>>>>> Best regards, >>>>>>> /Francis >>>>>>> ------------------------------ >>>>>>> *From:* TXAuth on behalf of Dick Hardt < >>>>>>> dick.hardt@gmail.com> >>>>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>>>>> *To:* Tom Jones >>>>>>> *Cc:* Fabien Imbault ; Denis < >>>>>>> denis.ietf@free.fr>; GNAP Mailing List ; Justin >>>>>>> Richer >>>>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>>>> >>>>>>> Got it. >>>>>>> >>>>>>> So web apps invoke a openid: deep link and hope there is an app to >>>>>>> handle the openid: scheme? ... and that it is the user's wallet rat= her than >>>>>>> some malware that has registered openid: on the mobile device? >>>>>>> >>>>>>> A native app can attempt to open a deep link associated with an app= , >>>>>>> and will fail if the app is not there. If the app is there, it will= be >>>>>>> opened, so this can't be used to silently test if an app is present= , but it >>>>>>> does allow a native app to provide an alternative experience if an = app is >>>>>>> not present. I don't think this works with custom schemes ... and I= don't >>>>>>> know how it could work from a web app on the phone with the current= Safari >>>>>>> APIs. >>>>>>> >>>>>>> Apple warns against using custom schemes [1] ... but perhaps they >>>>>>> can be convinced to make openid: a managed scheme similar to mailto= :, >>>>>>> tel:, sms:, facetime: ? >>>>>>> >>>>>>> [1] >>>>>>> https://developer.apple.com/documentation/xcode/allowing_apps_and_w= ebsites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app >>>>>>> >>>>>>> >>>>>>> =E1=90=A7 >>>>>>> >>>>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>> >>>>>>> You are - that is not standard which is opeind:// >>>>>>> This is the one step that still needs to be optimized for SIOP to >>>>>>> have good UX. >>>>>>> Peace ..tom >>>>>>> >>>>>>> >>>>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt >>>>>>> wrote: >>>>>>> >>>>>>> Hi Tom >>>>>>> >>>>>>> I watched your video (I watched at 2X speed) >>>>>>> >>>>>>> Looks like the employment website app that is using localhost:8765 >>>>>>> to communicate with the wallet. Am I correct? >>>>>>> >>>>>>> /Dick >>>>>>> =E1=90=A7 >>>>>>> >>>>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones < >>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>> >>>>>>> Well, here's a demo. Note that in this case the AS is not online al= l >>>>>>> of the time, so it is really implicit flow and the OIDC id-token co= mes from >>>>>>> the siop device directly. >>>>>>> (whether this is front-channel or back channel is no longer an >>>>>>> interesting question.) >>>>>>> Now if an always-on AS is required, that is possible, but probably >>>>>>> beyond the scope of this effort and would require something like an >>>>>>> agent-in-the-sky (with diamonds). >>>>>>> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 >>>>>>> >>>>>>> Peace ..tom >>>>>>> >>>>>>> >>>>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>> Ultimately, in most situations like these in the real world, the >>>>>>> hurdle isn=E2=80=99t technical compatibility so much as it is trust= compatibility. >>>>>>> The RP (client) needs to have some incentive to trust the assertion= s and >>>>>>> identity information that=E2=80=99s coming from the AS. The same is= true for an RS >>>>>>> trusting tokens from the AS. The hard question is less =E2=80=9Chow= =E2=80=9D to do that >>>>>>> (which SSI answers), but more =E2=80=9Cwhy=E2=80=9D to do that (whi= ch SSI doesn=E2=80=99t answer >>>>>>> very well, because it=E2=80=99s a hard question). >>>>>>> >>>>>>> Still: it=E2=80=99s definitely a question about how to support this= =E2=80=9CAS on >>>>>>> device=E2=80=9D element. We=E2=80=99ve got the start of it more tha= n OAuth2/OIDC have by >>>>>>> allowing the bootstrap of the process from a starting call: the int= eraction >>>>>>> and continuation URIs handed back by the AS don=E2=80=99t need to b= e the same URIs >>>>>>> that the client starts with, so just like SIOP the process can star= t in >>>>>>> HTTP and potentially move to other communication channels. A major >>>>>>> difference is that we aren=E2=80=99t dependent on the assumption th= at the user will >>>>>>> always be in a browser at some stage, and so the whole raft of >>>>>>> front-channel messages that SIOP relies on doesn=E2=80=99t fly. Tha= t said, we=E2=80=99ve >>>>>>> got an opportunity to more explicitly open up alternative communica= tion >>>>>>> channels here, and that=E2=80=99s something I=E2=80=99d like to see= engineered, even if >>>>>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete propo= sal as to how that would >>>>>>> work over specific protocols, starting with what we=E2=80=99ve got = today. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>> Hi Denis, hi Francis, >>>>>>> >>>>>>> At some point integration with SSI (on the authentication side) wil= l >>>>>>> probably occur, including amongst other possibilities SIOP (since t= hey work >>>>>>> with OpenID a part of the work will probably be made easier). >>>>>>> >>>>>>> That being said, Denis is right. It's not an AS. Technically it's >>>>>>> entirely possible to rely on a decentralized wallet (for instance o= n your >>>>>>> phone) and a centralized AS. I know of a few studies on how to dece= ntralize >>>>>>> the AS itself (for instance >>>>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >>>>>>> Maybe it exists, but I'm still looking for real scenarios (or even >>>>>>> architectures) where an AS is deployed directly on a phone, and und= er the >>>>>>> sole authority of the RO, while being compatible with the rest of t= he >>>>>>> world. >>>>>>> >>>>>>> Cheers, >>>>>>> Fabien >>>>>>> >>>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >>>>>>> >>>>>>> Hello Francis, >>>>>>> >>>>>>> See two comments in line. >>>>>>> >>>>>>> >>>>>>> B) Current Document >>>>>>> >>>>>>> Roles description shall not hold any assumption on the physical >>>>>>> structure of the party fulfilling the roles. >>>>>>> [FI] not sure what you mean >>>>>>> >>>>>>> [FP] for example, we assume the AS is a server! In most SSI based >>>>>>> use cases, the AS will be running on the user device. See SIOP ( >>>>>>> https://identity.foundation/did-siop/). >>>>>>> >>>>>>> I browsed through the two drafts, i.e. : >>>>>>> >>>>>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >>>>>>> model, and representations W3C Working Draft 08 November 2020 >>>>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF >>>>>>> Working Group Draft >>>>>>> >>>>>>> At no place within these two documents, it is possible to imagine >>>>>>> that "the AS will be running on the user device". >>>>>>> >>>>>>> From section 3 of the DIF Working Group Draft: >>>>>>> >>>>>>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], >>>>>>> the SIOP will not return an access token to the RP". >>>>>>> >>>>>>> An Identity Wallet is not an AS. >>>>>>> >>>>>>> >>>>>>> Roles: >>>>>>> -> grant endpoint of the AS: Why is this a post request? This >>>>>>> eliminates the chance of having user device hosted AS (no server). >>>>>>> [FI] what would you propose instead? >>>>>>> Would also be interested to understand better the deployment model >>>>>>> when there is no server. That's something that was discussed severa= l times >>>>>>> but I'm still missing the underlying architecture and use case. >>>>>>> >>>>>>> [FP] See above (SIOP). There will be a lot of identity wallets >>>>>>> operated on end user device. >>>>>>> >>>>>>> See the above comment. Please, do not confuse an Identity Wallet >>>>>>> with an Authentication Server (AS). >>>>>>> >>>>>>> Denis >>>>>>> >>>>>>> >>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it authorize >>>>>>> the request or the access to a resource? >>>>>>> [FI] yes, we should make the wording clearer >>>>>>> >>>>>>> Missing Section Interactions: >>>>>>> --> This section shall introduce the notion of interaction before w= e >>>>>>> start listing interaction types. >>>>>>> [FI] yes >>>>>>> >>>>>>> Interaction Types: >>>>>>> --> I prefer a classification with Redirect, Decoupled and Embedded >>>>>>> is. In the draft, we have one redirect and 2 decouple interactions = and >>>>>>> nothing else. >>>>>>> [FI] this should be handled as a specific discussion item. As a >>>>>>> reminder, how would you define embedded? >>>>>>> >>>>>>> In practice there's at least these modes: >>>>>>> - redirect and redirect back >>>>>>> - redirect to different browser or device >>>>>>> - user code >>>>>>> - CIBA >>>>>>> >>>>>>> [FP] This classification is limited. >>>>>>> >>>>>>> - Redirect: same device, same or different user agents (browser, >>>>>>> mobile app, desktop app, ...) >>>>>>> - Decoupled: different devices >>>>>>> - Embedded : RC carries RO authorization to AS >>>>>>> >>>>>>> >>>>>>> >>>>>>> Resource Access Request vs. Resource Request >>>>>>> --> Both are mixed up. No clarification of the context of each >>>>>>> section. >>>>>>> [FI] could you clarify what you'd expect. Btw on this topic, >>>>>>> there's a more general discussion on whether we should make a disti= nction >>>>>>> or not. >>>>>>> >>>>>>> =E2=80=8B[FP]: Here: >>>>>>> >>>>>>> - Resource Access Request: Requesting Access to a resource. >>>>>>> Response is an access token (or any type of grant) >>>>>>> - Resource Request: Request the resource. Response is the >>>>>>> resource (or a corresponding execution) >>>>>>> >>>>>>> >>>>>>> Token Content Negotiation >>>>>>> --> Not expressed as such. This is central to GNAP and not >>>>>>> represented enough in the document. >>>>>>> [FI] right. This should be a specific discussion item. >>>>>>> >>>>>>> Requesting "User" Information >>>>>>> we identify two types of users: RQ and RO. It will be better not to >>>>>>> refer to a user in this draft, but either to a RQ or an RO. >>>>>>> [FI] yes that would avoid potential misunderstandings. Although in >>>>>>> the end, people will translate RQ into user or end-user most of the= time. >>>>>>> Cf in definition, currently we have Requesting Party (RQ, aka >>>>>>> "user") >>>>>>> >>>>>>> >>>>>>> Interaction Again >>>>>>> -> For each interaction type, we will have to describe the protocol >>>>>>> flow and the nature and behavior of involved Roles (Parties), Eleme= nts, >>>>>>> Requests. >>>>>>> [FI] yes >>>>>>> >>>>>>> >>>>>>> [FP] Will these and into tickets? >>>>>>> >>>>>>> Best regards. >>>>>>> /Francis >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> >>> --000000000000a004b905ba869348 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok, to be enablers of change, we'd need to specify how= this would work in detail. Again I find the objective attractive, it's= just there a few technical hurdles along the way. HTTP has never been desi= gned for this use case.

On Thu, Feb 4, 2021 at 7:03 PM Tom Jones <thomasclinganjones@gmail.com&g= t; wrote:
Justin's analysis of use of the front channel is misleading.=
It could equally be argued that what i have done is installed an AS on= the phone and the communications with it & the PR is back channel.
Basically the point is that the old OIDC paradigms are no longer val= id.
Be the change you wa= nt to see in the world ..tom

=
On Thu= , Feb 4, 2021 at 7:47 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
<= /div>
Yes= , issue (#168)=C2=A0message based interaction / DIDComm is a tentative alte= rnative mecanism for the interaction part. Not sure how that would work in = details=C2=A0though, prototyping will probably help here.
Token deliver= y=C2=A0through continuation seems fine to me. The client will probably have= to wait for the next polling before it receives a token issued as the resu= lt of an asynchronous interaction, but that's not a big issue.

But the AS on the phone seems like a harder nut to crack, = at least at first sight. I think that would be awesome, but it gives me hea= daches, so I think I'll work on easier stuff right now ;-)
Fabien=C2=A0=C2=A0

On Thu, Feb 4, 2021 at 4:30 PM Jus= tin Richer <jricher= @mit.edu> wrote:
One of the biggest drawbacks of the current app-centric approa= ches in OIDC (self-issued OP, or SIOP) is that they depend on using the fro= nt channel and browser redirects to pass everything, which is something tha= t GNAP is deliberately getting away from by starting in the back channel.
That said, once a request is kicked off in GNAP, the inte= raction and fulfillment can happen through any number of means. Part of the= work that=E2=80=99s being done with the =E2=80=9Cinteraction=E2=80=9D sect= ion is going to help facilitate this, and I think that there are some other= potential branches here.

Token delivery is where = things get extra weird though =E2=80=94 we are explicitly not delivering to= kens in the front channel in the core of GNAP, we=E2=80=99re using the resp= onse from the continuation API. One idea (that isn=E2=80=99t particularly w= ell thought out and hasn=E2=80=99t been implemented at all) is to have an e= xtension declare an alternative response from the =E2=80=9Ccontinue=E2=80= =9D section that=E2=80=99s defined today, which points to the GNPA continua= tion API. If an extension defines some alternative way to deliver tokens, t= hat could live alongside a continuation API and the client could indicate s= upport for it in its initial request.

In any event= , alternative interaction and delivery methods are important, and even if w= e aren=E2=80=99t going to support every last one of them directly, the prot= ocol design should at least be aware of them.

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

On Feb 4, 20= 21, at 8:35 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Tom,=C2=A0

Sure, any experience on = that would be greatly appreciated, we're calling for help here (the poi= nt being that I suspect what they're doing is not trivial).
<= br>
Fabien

On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclingan= jones@gmail.com> wrote:
I've had such an app working for over = a year. There are issues which are being addressed by the browser Interacti= on team of oidc.

thx ..Tom (mobile)

On Thu, Feb 4, 2021,= 3:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,=C2=A0
I've tried a few things with regards to using the AS = on a phone, but it's really quite=C2=A0complex.=C2=A0

Making that run on a phone comes with quite a bit of trouble. The m= ost difficult part if that we'd need to use a secure element, but just = installing and hosting a http server securely is not a standard setup at al= l. I suggest interested people step in to work on this, as we already have = a lot of work for the (more usual) server case and already handle a privacy= preserving scheme.=C2=A0

Please let us know what = you think.

Cheers,
Fabien=C2=A0

On = Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault <fabien.imbault@gmail.= com> wrote:
Hi Francis,

I've thought a bit more to what you said. I think I'll gi= ve it a try as a separate experiment (in code, not in theory). Not that I w= ould expect it to be included in GNAP, but I kind of like the idea :-)

The direct impact for GNAP w= ould be to think about multiple ASs.=C2=A0

Will let you know.=C2=A0

Fabien=C2=A0


Le mer. 18 nov. 2020 =C3=A0 13:06, Fran= cis Pouatcha <fpo@adorsys.de> a =C3=A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"gmail-m_7388824188029334085gmail-m_-3037161202240578685gmail-m_-7520389= 457378808664gmail-m_-3342024782330569254m_8014700032835912204gmail-m_142651= 873244800559m_8348797445460806175LPlnk338391" rel=3D"noreferrer noreferrer"= target=3D"_blank">https://github.com/ietf-wg-gnap/gnap-core-protocol/issue= s/30).

/Francis

From: Fabien Imb= ault <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>;= Dick Hardt <dick.hardt@gmail.com>; Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-bounces@ietf.org&= gt; on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com<= /a>>
Cc: Fabien Imbault <fabien.imbault@gmail.com= >; Denis <denis.ietf@free.fr>; GNAP Mailing List &l= t;txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://yo= utu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabi= en.imbault@gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentralized= -02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis= .ietf@free.fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundati= on/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= =E2=80=8B= [FP]: Here:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth

--000000000000a004b905ba869348-- From nobody Thu Feb 4 10:18:02 2021 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 0CEC03A16E3 for ; Thu, 4 Feb 2021 10:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 d1XargBFSeQJ for ; Thu, 4 Feb 2021 10:17:57 -0800 (PST) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 2157B3A0DCD for ; Thu, 4 Feb 2021 10:17:57 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id j25so4718796oii.0 for ; Thu, 04 Feb 2021 10:17:57 -0800 (PST) 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=3nFt59SzNgXHg4SsD1QVvFxarfNqdMtXWVHBcU/ze+4=; b=bzWau9I+1tl99s2rPnb9lLpk8mRci0/lxzdYq7PtmJVNMlfxnNkgTotDXfxPrHz55X naa7QOIr42nukDERAoTgJHwD8UPj1zURzoRgfPBZLy0A3UBFUv35g09r9KNY674AgBNa eaqX9MFnxfCYlZk46x1X2iY7jud2s9uc8tgZ8uQNRCCseKVpXo5mR3rcZ5VS684X/7qj 3HQMSViDshO94ajjeLBWf1T5E5+g4NmdDmgpDbth5ssHes/l+B+CS0fLRXGr+MPyBzk6 6AaZHsIjjJMDLbRHKQ6/X4iUjAjEztjBJiqGbb8vSp9BfegSyy6mFlDMk/iKvW2P1JIE kuAA== 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=3nFt59SzNgXHg4SsD1QVvFxarfNqdMtXWVHBcU/ze+4=; b=ZlHWV7t2IUQbYEMwURdhUnW76eOtJov8zSzU2XV/6CUOIwY2W7zVh26k+OgcTZzbjL cH0SNf/95ya9XBWVBYk3DeVs/c4r3mFOTS6INCe4WmFXVTsPzj0LMBGRDf1OK4b6OiMp 9EDW27zm4vazcRvedBkU4mrm4SKxYY9eGOmR7dD+f+12bjEQ2FpnUQKlU44Dbk5CXz/C fhhlN3sUTfutTzUKXRj/vEMaXgAEKLt1mMpru5V8dMYDY8j+2AQwlLyORxugZKFgofc1 v1Ycigby8h52DT85hw1eI88mL9OFYfEMBn6opKzpFdUbf2Wsp/uJQg7uYVwc2GAZK9aH blpg== X-Gm-Message-State: AOAM532b3X1albBLTHEwQhwuU+v6aNXMSxqo+FvNgCGDwXrAl5Q4ENAp lmV77GQ95ysgLOBXGLm+OkA5VYKemzmWSTGCh8g= X-Google-Smtp-Source: ABdhPJyLTH5wRf0589a8ykJ15/7ngEYnIidv0jkcSHqXgdUdBGW52E06Nue4JhtQAbJYS4yx87zs8+BAUkuMbc5Xmlk= X-Received: by 2002:aca:4fd5:: with SMTP id d204mr518699oib.172.1612462676294; Thu, 04 Feb 2021 10:17:56 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> In-Reply-To: From: Tom Jones Date: Thu, 4 Feb 2021 10:17:44 -0800 Message-ID: To: Fabien Imbault Cc: Justin Richer , Francis Pouatcha , GNAP Mailing List , Dick Hardt , Denis Content-Type: multipart/alternative; boundary="00000000000008c29905ba86b98b" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 18:18:01 -0000 --00000000000008c29905ba86b98b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The problem IMHO is getting support from the browsers. That is what the new task group is attempting to do. W/O that phones will not IMHO be very successful with things like GNAP. (HTTP really is not the issue) Be the change you want to see in the world ..tom On Thu, Feb 4, 2021 at 10:07 AM Fabien Imbault wrote: > Ok, to be enablers of change, we'd need to specify how this would work in > detail. Again I find the objective attractive, it's just there a few > technical hurdles along the way. HTTP has never been designed for this us= e > case. > > On Thu, Feb 4, 2021 at 7:03 PM Tom Jones > wrote: > >> Justin's analysis of use of the front channel is misleading. >> It could equally be argued that what i have done is installed an AS on >> the phone and the communications with it & the PR is back channel. >> Basically the point is that the old OIDC paradigms are no longer valid. >> Be the change you want to see in the world ..tom >> >> >> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault >> wrote: >> >>> Yes, issue (#168) message based interaction / DIDComm is a tentative >>> alternative mecanism for the interaction part. Not sure how that would = work >>> in details though, prototyping will probably help here. >>> Token delivery through continuation seems fine to me. The client will >>> probably have to wait for the next polling before it receives a token >>> issued as the result of an asynchronous interaction, but that's not a b= ig >>> issue. >>> >>> But the AS on the phone seems like a harder nut to crack, at least at >>> first sight. I think that would be awesome, but it gives me headaches, = so I >>> think I'll work on easier stuff right now ;-) >>> >>> Fabien >>> >>> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer wrote: >>> >>>> One of the biggest drawbacks of the current app-centric approaches in >>>> OIDC (self-issued OP, or SIOP) is that they depend on using the front >>>> channel and browser redirects to pass everything, which is something t= hat >>>> GNAP is deliberately getting away from by starting in the back channel= . >>>> >>>> That said, once a request is kicked off in GNAP, the interaction and >>>> fulfillment can happen through any number of means. Part of the work t= hat=E2=80=99s >>>> being done with the =E2=80=9Cinteraction=E2=80=9D section is going to = help facilitate this, >>>> and I think that there are some other potential branches here. >>>> >>>> Token delivery is where things get extra weird though =E2=80=94 we are >>>> explicitly not delivering tokens in the front channel in the core of G= NAP, >>>> we=E2=80=99re using the response from the continuation API. One idea (= that isn=E2=80=99t >>>> particularly well thought out and hasn=E2=80=99t been implemented at a= ll) is to >>>> have an extension declare an alternative response from the =E2=80=9Cco= ntinue=E2=80=9D >>>> section that=E2=80=99s defined today, which points to the GNPA continu= ation API. If >>>> an extension defines some alternative way to deliver tokens, that coul= d >>>> live alongside a continuation API and the client could indicate suppor= t for >>>> it in its initial request. >>>> >>>> In any event, alternative interaction and delivery methods are >>>> important, and even if we aren=E2=80=99t going to support every last o= ne of them >>>> directly, the protocol design should at least be aware of them. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault >>>> wrote: >>>> >>>> Hi Tom, >>>> >>>> Sure, any experience on that would be greatly appreciated, we're >>>> calling for help here (the point being that I suspect what they're doi= ng is >>>> not trivial). >>>> >>>> Fabien >>>> >>>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones >>>> wrote: >>>> >>>>> I've had such an app working for over a year. There are issues which >>>>> are being addressed by the browser Interaction team of oidc. >>>>> >>>>> thx ..Tom (mobile) >>>>> >>>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault >>>>> wrote: >>>>> >>>>>> Hi Francis, >>>>>> >>>>>> I've tried a few things with regards to using the AS on a phone, but >>>>>> it's really quite complex. >>>>>> >>>>>> Making that run on a phone comes with quite a bit of trouble. The >>>>>> most difficult part if that we'd need to use a secure element, but j= ust >>>>>> installing and hosting a http server securely is not a standard setu= p at >>>>>> all. I suggest interested people step in to work on this, as we alre= ady >>>>>> have a lot of work for the (more usual) server case and already hand= le a >>>>>> privacy preserving scheme. >>>>>> >>>>>> Please let us know what you think. >>>>>> >>>>>> Cheers, >>>>>> Fabien >>>>>> >>>>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Hi Francis, >>>>>>> >>>>>>> I've thought a bit more to what you said. I think I'll give it a tr= y >>>>>>> as a separate experiment (in code, not in theory). Not that I would= expect >>>>>>> it to be included in GNAP, but I kind of like the idea :-) >>>>>>> >>>>>>> The direct impact for GNAP would be to think about multiple ASs. >>>>>>> >>>>>>> Will let you know. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha a >>>>>>> =C3=A9crit : >>>>>>> >>>>>>>> It would be nice if the protocol was designed at many layers of >>>>>>>> abstraction. >>>>>>>> >>>>>>>> >>>>>>>> - The first layer shall design abstract protocol flows, without >>>>>>>> specification of the mode and mechanism of interaction. >>>>>>>> - The second layer can instantiate the first layer for >>>>>>>> dedicated interaction. Here we can talk http, we can define int= eractions >>>>>>>> that presume server based token generation, we can define inter= action that >>>>>>>> run on user device based token generation. >>>>>>>> >>>>>>>> This is also the fundament of the structure I proposed for the spe= c >>>>>>>> (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). >>>>>>>> >>>>>>>> /Francis >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> *From:* Fabien Imbault >>>>>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>>>>>> *To:* Francis Pouatcha >>>>>>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>>>>>> dick.hardt@gmail.com>; Tom Jones ; >>>>>>>> Denis ; Justin Richer >>>>>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>>>>> >>>>>>>> Would make sense, but not so easy as we rely heavily on HTTP. Henc= e >>>>>>>> the discussion about deep links and so on. >>>>>>>> >>>>>>>> An alternative might be provided by wasm/wasi (running a local >>>>>>>> sandbox on your phone, for your own AS), but it's really early sta= ge. This >>>>>>>> also poses another question that Denis has put forward, i.e. how d= o we >>>>>>>> handle the multiple AS scenario (likely to occur then). >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha >>>>>>>> wrote: >>>>>>>> >>>>>>>> We are drifting away from the original problem space. >>>>>>>> >>>>>>>> - My original mention was about the "POST" request, that >>>>>>>> subsumes that the "AS" is a "Server". Designing a new protocol,= we cannot >>>>>>>> afford this limitation. >>>>>>>> - I just mentioned SIOP to show a known and closed example? Let >>>>>>>> us not focus on the device local discovery scheme (like openid:= ) for now. >>>>>>>> - As capability of holding private keys on user device evolves, >>>>>>>> server-based issuing of token will be fading out giving way to = device local >>>>>>>> generation of token. >>>>>>>> >>>>>>>> While designing GNAP, let us assume the AS-Role can be exercised o= n >>>>>>>> a user device and design the protocol to honor that. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> /Francis >>>>>>>> ------------------------------ >>>>>>>> *From:* TXAuth on behalf of Dick Hardt < >>>>>>>> dick.hardt@gmail.com> >>>>>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>>>>>> *To:* Tom Jones >>>>>>>> *Cc:* Fabien Imbault ; Denis < >>>>>>>> denis.ietf@free.fr>; GNAP Mailing List ; Justin >>>>>>>> Richer >>>>>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>>>>> >>>>>>>> Got it. >>>>>>>> >>>>>>>> So web apps invoke a openid: deep link and hope there is an app to >>>>>>>> handle the openid: scheme? ... and that it is the user's wallet ra= ther than >>>>>>>> some malware that has registered openid: on the mobile device? >>>>>>>> >>>>>>>> A native app can attempt to open a deep link associated with an >>>>>>>> app, and will fail if the app is not there. If the app is there, i= t will be >>>>>>>> opened, so this can't be used to silently test if an app is presen= t, but it >>>>>>>> does allow a native app to provide an alternative experience if an= app is >>>>>>>> not present. I don't think this works with custom schemes ... and = I don't >>>>>>>> know how it could work from a web app on the phone with the curren= t Safari >>>>>>>> APIs. >>>>>>>> >>>>>>>> Apple warns against using custom schemes [1] ... but perhaps they >>>>>>>> can be convinced to make openid: a managed scheme similar to mailt= o:, >>>>>>>> tel:, sms:, facetime: ? >>>>>>>> >>>>>>>> [1] >>>>>>>> https://developer.apple.com/documentation/xcode/allowing_apps_and_= websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app >>>>>>>> >>>>>>>> >>>>>>>> =E1=90=A7 >>>>>>>> >>>>>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>> >>>>>>>> You are - that is not standard which is opeind:// >>>>>>>> This is the one step that still needs to be optimized for SIOP to >>>>>>>> have good UX. >>>>>>>> Peace ..tom >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Tom >>>>>>>> >>>>>>>> I watched your video (I watched at 2X speed) >>>>>>>> >>>>>>>> Looks like the employment website app that is using localhost:8765 >>>>>>>> to communicate with the wallet. Am I correct? >>>>>>>> >>>>>>>> /Dick >>>>>>>> =E1=90=A7 >>>>>>>> >>>>>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones < >>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>> >>>>>>>> Well, here's a demo. Note that in this case the AS is not online >>>>>>>> all of the time, so it is really implicit flow and the OIDC id-tok= en comes >>>>>>>> from the siop device directly. >>>>>>>> (whether this is front-channel or back channel is no longer an >>>>>>>> interesting question.) >>>>>>>> Now if an always-on AS is required, that is possible, but probably >>>>>>>> beyond the scope of this effort and would require something like a= n >>>>>>>> agent-in-the-sky (with diamonds). >>>>>>>> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 >>>>>>>> >>>>>>>> Peace ..tom >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>> Ultimately, in most situations like these in the real world, the >>>>>>>> hurdle isn=E2=80=99t technical compatibility so much as it is trus= t compatibility. >>>>>>>> The RP (client) needs to have some incentive to trust the assertio= ns and >>>>>>>> identity information that=E2=80=99s coming from the AS. The same i= s true for an RS >>>>>>>> trusting tokens from the AS. The hard question is less =E2=80=9Cho= w=E2=80=9D to do that >>>>>>>> (which SSI answers), but more =E2=80=9Cwhy=E2=80=9D to do that (wh= ich SSI doesn=E2=80=99t answer >>>>>>>> very well, because it=E2=80=99s a hard question). >>>>>>>> >>>>>>>> Still: it=E2=80=99s definitely a question about how to support thi= s =E2=80=9CAS on >>>>>>>> device=E2=80=9D element. We=E2=80=99ve got the start of it more th= an OAuth2/OIDC have by >>>>>>>> allowing the bootstrap of the process from a starting call: the in= teraction >>>>>>>> and continuation URIs handed back by the AS don=E2=80=99t need to = be the same URIs >>>>>>>> that the client starts with, so just like SIOP the process can sta= rt in >>>>>>>> HTTP and potentially move to other communication channels. A major >>>>>>>> difference is that we aren=E2=80=99t dependent on the assumption t= hat the user will >>>>>>>> always be in a browser at some stage, and so the whole raft of >>>>>>>> front-channel messages that SIOP relies on doesn=E2=80=99t fly. Th= at said, we=E2=80=99ve >>>>>>>> got an opportunity to more explicitly open up alternative communic= ation >>>>>>>> channels here, and that=E2=80=99s something I=E2=80=99d like to se= e engineered, even if >>>>>>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would >>>>>>>> work over specific protocols, starting with what we=E2=80=99ve got= today. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>> Hi Denis, hi Francis, >>>>>>>> >>>>>>>> At some point integration with SSI (on the authentication side) >>>>>>>> will probably occur, including amongst other possibilities SIOP (s= ince they >>>>>>>> work with OpenID a part of the work will probably be made easier). >>>>>>>> >>>>>>>> That being said, Denis is right. It's not an AS. Technically it's >>>>>>>> entirely possible to rely on a decentralized wallet (for instance = on your >>>>>>>> phone) and a centralized AS. I know of a few studies on how to dec= entralize >>>>>>>> the AS itself (for instance >>>>>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02)= . >>>>>>>> Maybe it exists, but I'm still looking for real scenarios (or even >>>>>>>> architectures) where an AS is deployed directly on a phone, and un= der the >>>>>>>> sole authority of the RO, while being compatible with the rest of = the >>>>>>>> world. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Fabien >>>>>>>> >>>>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >>>>>>>> >>>>>>>> Hello Francis, >>>>>>>> >>>>>>>> See two comments in line. >>>>>>>> >>>>>>>> >>>>>>>> B) Current Document >>>>>>>> >>>>>>>> Roles description shall not hold any assumption on the physical >>>>>>>> structure of the party fulfilling the roles. >>>>>>>> [FI] not sure what you mean >>>>>>>> >>>>>>>> [FP] for example, we assume the AS is a server! In most SSI based >>>>>>>> use cases, the AS will be running on the user device. See SIOP ( >>>>>>>> https://identity.foundation/did-siop/). >>>>>>>> >>>>>>>> I browsed through the two drafts, i.e. : >>>>>>>> >>>>>>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >>>>>>>> model, and representations W3C Working Draft 08 November 2020 >>>>>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF >>>>>>>> Working Group Draft >>>>>>>> >>>>>>>> At no place within these two documents, it is possible to imagine >>>>>>>> that "the AS will be running on the user device". >>>>>>>> >>>>>>>> From section 3 of the DIF Working Group Draft: >>>>>>>> >>>>>>>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], >>>>>>>> the SIOP will not return an access token to the RP". >>>>>>>> >>>>>>>> An Identity Wallet is not an AS. >>>>>>>> >>>>>>>> >>>>>>>> Roles: >>>>>>>> -> grant endpoint of the AS: Why is this a post request? This >>>>>>>> eliminates the chance of having user device hosted AS (no server). >>>>>>>> [FI] what would you propose instead? >>>>>>>> Would also be interested to understand better the deployment model >>>>>>>> when there is no server. That's something that was discussed sever= al times >>>>>>>> but I'm still missing the underlying architecture and use case. >>>>>>>> >>>>>>>> [FP] See above (SIOP). There will be a lot of identity wallets >>>>>>>> operated on end user device. >>>>>>>> >>>>>>>> See the above comment. Please, do not confuse an Identity Wallet >>>>>>>> with an Authentication Server (AS). >>>>>>>> >>>>>>>> Denis >>>>>>>> >>>>>>>> >>>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it authorize >>>>>>>> the request or the access to a resource? >>>>>>>> [FI] yes, we should make the wording clearer >>>>>>>> >>>>>>>> Missing Section Interactions: >>>>>>>> --> This section shall introduce the notion of interaction before >>>>>>>> we start listing interaction types. >>>>>>>> [FI] yes >>>>>>>> >>>>>>>> Interaction Types: >>>>>>>> --> I prefer a classification with Redirect, Decoupled and Embedde= d >>>>>>>> is. In the draft, we have one redirect and 2 decouple interactions= and >>>>>>>> nothing else. >>>>>>>> [FI] this should be handled as a specific discussion item. As a >>>>>>>> reminder, how would you define embedded? >>>>>>>> >>>>>>>> In practice there's at least these modes: >>>>>>>> - redirect and redirect back >>>>>>>> - redirect to different browser or device >>>>>>>> - user code >>>>>>>> - CIBA >>>>>>>> >>>>>>>> [FP] This classification is limited. >>>>>>>> >>>>>>>> - Redirect: same device, same or different user agents >>>>>>>> (browser, mobile app, desktop app, ...) >>>>>>>> - Decoupled: different devices >>>>>>>> - Embedded : RC carries RO authorization to AS >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Resource Access Request vs. Resource Request >>>>>>>> --> Both are mixed up. No clarification of the context of each >>>>>>>> section. >>>>>>>> [FI] could you clarify what you'd expect. Btw on this topic, >>>>>>>> there's a more general discussion on whether we should make a dist= inction >>>>>>>> or not. >>>>>>>> >>>>>>>> =E2=80=8B[FP]: Here: >>>>>>>> >>>>>>>> - Resource Access Request: Requesting Access to a resource. >>>>>>>> Response is an access token (or any type of grant) >>>>>>>> - Resource Request: Request the resource. Response is the >>>>>>>> resource (or a corresponding execution) >>>>>>>> >>>>>>>> >>>>>>>> Token Content Negotiation >>>>>>>> --> Not expressed as such. This is central to GNAP and not >>>>>>>> represented enough in the document. >>>>>>>> [FI] right. This should be a specific discussion item. >>>>>>>> >>>>>>>> Requesting "User" Information >>>>>>>> we identify two types of users: RQ and RO. It will be better not t= o >>>>>>>> refer to a user in this draft, but either to a RQ or an RO. >>>>>>>> [FI] yes that would avoid potential misunderstandings. Although in >>>>>>>> the end, people will translate RQ into user or end-user most of th= e time. >>>>>>>> Cf in definition, currently we have Requesting Party (RQ, aka >>>>>>>> "user") >>>>>>>> >>>>>>>> >>>>>>>> Interaction Again >>>>>>>> -> For each interaction type, we will have to describe the protoco= l >>>>>>>> flow and the nature and behavior of involved Roles (Parties), Elem= ents, >>>>>>>> Requests. >>>>>>>> [FI] yes >>>>>>>> >>>>>>>> >>>>>>>> [FP] Will these and into tickets? >>>>>>>> >>>>>>>> Best regards. >>>>>>>> /Francis >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>>> >>>> --00000000000008c29905ba86b98b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The problem IMHO is getting support from the browsers. Tha= t is what the new task group is attempting to do. W/O that phones will not = IMHO be very successful with things like GNAP.=C2=A0 (HTTP really is not th= e issue)

Be the change you want t= o see in the world ..tom


=
On Thu, Fe= b 4, 2021 at 10:07 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Ok, to be enablers of ch= ange, we'd need to specify how this would work in detail. Again I find = the objective attractive, it's just there a few technical hurdles along= the way. HTTP has never been designed for this use case.

On Thu, Feb 4, 202= 1 at 7:03 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
Justin's= analysis of use of the front channel is misleading.
It could equally b= e argued that what i have done is installed an AS on the phone and the comm= unications with it & the PR is back channel.
Basically the po= int is that the old OIDC paradigms are no longer valid.
Be the change you want to see in the world = ..tom


On Thu, Feb 4, 2021 at 7:47 A= M Fabien Imbault <fabien.imbault@gmail.com> wrote:
Yes, issue (#168)=C2=A0me= ssage based interaction / DIDComm is a tentative alternative mecanism for t= he interaction part. Not sure how that would work in details=C2=A0though, p= rototyping will probably help here.
Token delivery=C2=A0through continu= ation seems fine to me. The client will probably have to wait for the next = polling before it receives a token issued as the result of an asynchronous = interaction, but that's not a big issue.

But t= he AS on the phone seems like a harder nut to crack, at least at first sigh= t. I think that would be awesome, but it gives me headaches, so I think I&#= 39;ll work on easier stuff right now ;-)

Fabien=C2= =A0=C2=A0

On Thu, Feb 4, 2021 at 4:30 PM Justin Richer <jricher@mit.edu> wrote= :
One of th= e biggest drawbacks of the current app-centric approaches in OIDC (self-iss= ued OP, or SIOP) is that they depend on using the front channel and browser= redirects to pass everything, which is something that GNAP is deliberately= getting away from by starting in the back channel.

That= said, once a request is kicked off in GNAP, the interaction and fulfillmen= t can happen through any number of means. Part of the work that=E2=80=99s b= eing done with the =E2=80=9Cinteraction=E2=80=9D section is going to help f= acilitate this, and I think that there are some other potential branches he= re.

Token delivery is where things get extra weird= though =E2=80=94 we are explicitly not delivering tokens in the front chan= nel in the core of GNAP, we=E2=80=99re using the response from the continua= tion API. One idea (that isn=E2=80=99t particularly well thought out and ha= sn=E2=80=99t been implemented at all) is to have an extension declare an al= ternative response from the =E2=80=9Ccontinue=E2=80=9D section that=E2=80= =99s defined today, which points to the GNPA continuation API. If an extens= ion defines some alternative way to deliver tokens, that could live alongsi= de a continuation API and the client could indicate support for it in its i= nitial request.

In any event, alternative interact= ion and delivery methods are important, and even if we aren=E2=80=99t going= to support every last one of them directly, the protocol design should at = least be aware of them.

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

On Feb 4, 2021, at 8:35 AM, Fabien = Imbault <f= abien.imbault@gmail.com> wrote:

Hi To= m,=C2=A0

Sure, any experience on that would be greatly a= ppreciated, we're calling for help here (the point being that I suspect= what they're doing is not trivial).

Fabien

On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com>= wrote:
I've had such an app working for over a year. There are issue= s which are being addressed by the browser Interaction team of oidc.
thx ..Tom (mobile)

On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault &= lt;fabien.imb= ault@gmail.com> wrote:
Hi Francis,=C2=A0

I'v= e tried a few things with regards to using the AS on a phone, but it's = really quite=C2=A0complex.=C2=A0

Making that run o= n a phone comes with quite a bit of trouble. The most difficult part if tha= t we'd need to use a secure element, but just installing and hosting a = http server securely is not a standard setup at all. I suggest interested p= eople step in to work on this, as we already have a lot of work for the (mo= re usual) server case and already handle a privacy preserving scheme.=C2=A0=

Please let us know what you think.

=
Cheers,
Fabien=C2=A0

On Tue, Nov 24, 2020 at 5:55= AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,

I've thought = a bit more to what you said. I think I'll give it a try as a separate e= xperiment (in code, not in theory). Not that I would expect it to be includ= ed in GNAP, but I kind of like the idea :-)

The direct impact for GNAP would be to think about mult= iple ASs.=C2=A0

Will let= you know.=C2=A0

Fabien= =C2=A0


Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha <fpo@adorsys= .de> a =C3=A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"gmail-m_3679064657902611034gmail-m_7388824188029334085gmail-m_-30371612= 02240578685gmail-m_-7520389457378808664gmail-m_-3342024782330569254m_801470= 0032835912204gmail-m_142651873244800559m_8348797445460806175LPlnk338391" re= l=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/ietf-wg-gn= ap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <fabien.imbault@gmail.c= om>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>;= Dick Hardt <dick.hardt@gmail.com>; Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <t= xauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com<= /a>>
Cc: Fabien Imbault <fabien.imbault@gmail.com= >; Denis <denis.ietf@free.fr>; GNAP Mailing List &l= t;txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://yo= utu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabi= en.imbault@gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentralized= -02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis= .ietf@free.fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundati= on/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= =E2=80=8B= [FP]: Here:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth

--00000000000008c29905ba86b98b-- From nobody Thu Feb 4 11:01:54 2021 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 D5A943A172A for ; Thu, 4 Feb 2021 11:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, PDS_SHORTFWD_URISHRT_QP=1.498, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 OT5lbiDz4Ydp for ; Thu, 4 Feb 2021 11:01:48 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2153A1728 for ; Thu, 4 Feb 2021 11:01:47 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 114J1ev3014909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 4 Feb 2021 14:01:41 -0500 From: Justin Richer Message-Id: <77D1AE7B-076F-4095-8FAA-7C35D74614BD@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_48C4C212-7BF3-4DEB-9543-C1C8E445AA74" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 4 Feb 2021 14:01:40 -0500 In-Reply-To: Cc: Fabien Imbault , Denis , Francis Pouatcha , GNAP Mailing List , Dick Hardt To: Tom Jones References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 19:01:53 -0000 --Apple-Mail=_48C4C212-7BF3-4DEB-9543-C1C8E445AA74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tom, can you expand on how exactly the back-channel communication works = between on-device components? Do you use HTTP locally? Thanks, =E2=80=94 Justin > On Feb 4, 2021, at 1:03 PM, Tom Jones = wrote: >=20 > Justin's analysis of use of the front channel is misleading. > It could equally be argued that what i have done is installed an AS on = the phone and the communications with it & the PR is back channel. > Basically the point is that the old OIDC paradigms are no longer = valid. > Be the change you want to see in the world ..tom >=20 >=20 > On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault = > wrote: > Yes, issue (#168) message based interaction / DIDComm is a tentative = alternative mecanism for the interaction part. Not sure how that would = work in details though, prototyping will probably help here. > Token delivery through continuation seems fine to me. The client will = probably have to wait for the next polling before it receives a token = issued as the result of an asynchronous interaction, but that's not a = big issue. >=20 > But the AS on the phone seems like a harder nut to crack, at least at = first sight. I think that would be awesome, but it gives me headaches, = so I think I'll work on easier stuff right now ;-) >=20 > Fabien =20 >=20 > On Thu, Feb 4, 2021 at 4:30 PM Justin Richer > wrote: > One of the biggest drawbacks of the current app-centric approaches in = OIDC (self-issued OP, or SIOP) is that they depend on using the front = channel and browser redirects to pass everything, which is something = that GNAP is deliberately getting away from by starting in the back = channel. >=20 > That said, once a request is kicked off in GNAP, the interaction and = fulfillment can happen through any number of means. Part of the work = that=E2=80=99s being done with the =E2=80=9Cinteraction=E2=80=9D section = is going to help facilitate this, and I think that there are some other = potential branches here. >=20 > Token delivery is where things get extra weird though =E2=80=94 we are = explicitly not delivering tokens in the front channel in the core of = GNAP, we=E2=80=99re using the response from the continuation API. One = idea (that isn=E2=80=99t particularly well thought out and hasn=E2=80=99t = been implemented at all) is to have an extension declare an alternative = response from the =E2=80=9Ccontinue=E2=80=9D section that=E2=80=99s = defined today, which points to the GNPA continuation API. If an = extension defines some alternative way to deliver tokens, that could = live alongside a continuation API and the client could indicate support = for it in its initial request. >=20 > In any event, alternative interaction and delivery methods are = important, and even if we aren=E2=80=99t going to support every last one = of them directly, the protocol design should at least be aware of them. >=20 > =E2=80=94 Justin >=20 >> On Feb 4, 2021, at 8:35 AM, Fabien Imbault > wrote: >>=20 >> Hi Tom,=20 >>=20 >> Sure, any experience on that would be greatly appreciated, we're = calling for help here (the point being that I suspect what they're doing = is not trivial). >>=20 >> Fabien >>=20 >> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones = > = wrote: >> I've had such an app working for over a year. There are issues which = are being addressed by the browser Interaction team of oidc. >>=20 >> thx ..Tom (mobile) >>=20 >> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault > wrote: >> Hi Francis,=20 >>=20 >> I've tried a few things with regards to using the AS on a phone, but = it's really quite complex.=20 >>=20 >> Making that run on a phone comes with quite a bit of trouble. The = most difficult part if that we'd need to use a secure element, but just = installing and hosting a http server securely is not a standard setup at = all. I suggest interested people step in to work on this, as we already = have a lot of work for the (more usual) server case and already handle a = privacy preserving scheme.=20 >>=20 >> Please let us know what you think. >>=20 >> Cheers, >> Fabien=20 >>=20 >> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault = > wrote: >> Hi Francis, >>=20 >> I've thought a bit more to what you said. I think I'll give it a try = as a separate experiment (in code, not in theory). Not that I would = expect it to be included in GNAP, but I kind of like the idea :-) >>=20 >> The direct impact for GNAP would be to think about multiple ASs.=20 >>=20 >> Will let you know.=20 >>=20 >> Fabien=20 >>=20 >>=20 >> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha > a =C3=A9crit : >> It would be nice if the protocol was designed at many layers of = abstraction. >>=20 >> The first layer shall design abstract protocol flows, without = specification of the mode and mechanism of interaction. >> The second layer can instantiate the first layer for dedicated = interaction. Here we can talk http, we can define interactions that = presume server based token generation, we can define interaction that = run on user device based token generation. >> This is also the fundament of the structure I proposed for the spec = (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30 = ). >>=20 >> /Francis >>=20 >> From: Fabien Imbault > >> Sent: Wednesday, November 18, 2020 6:35 AM >> To: Francis Pouatcha > >> Cc: txauth@ietf.org >; Dick Hardt >; Tom Jones >; Denis >; Justin Richer > >> Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >> =20 >> Would make sense, but not so easy as we rely heavily on HTTP. Hence = the discussion about deep links and so on. >>=20 >> An alternative might be provided by wasm/wasi (running a local = sandbox on your phone, for your own AS), but it's really early stage. = This also poses another question that Denis has put forward, i.e. how do = we handle the multiple AS scenario (likely to occur then).=20 >>=20 >> Fabien=20 >>=20 >> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha > wrote: >> We are drifting away from the original problem space. >> My original mention was about the "POST" request, that subsumes that = the "AS" is a "Server". Designing a new protocol, we cannot afford this = limitation. >> I just mentioned SIOP to show a known and closed example? Let us not = focus on the device local discovery scheme (like openid:) for now. >> As capability of holding private keys on user device evolves, = server-based issuing of token will be fading out giving way to device = local generation of token. >> While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that. >>=20 >> Best regards, >> /Francis >> From: TXAuth > on behalf of Dick Hardt = > >> Sent: Tuesday, November 17, 2020 1:28 PM >> To: Tom Jones > >> Cc: Fabien Imbault >; Denis >; GNAP Mailing List >; Justin Richer > >> Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >> =20 >> Got it.=20 >>=20 >> So web apps invoke a openid: deep link and hope there is an app to = handle the openid: scheme? ... and that it is the user's wallet rather = than some malware that has registered openid: on the mobile device? >>=20 >> A native app can attempt to open a deep link associated with an app, = and will fail if the app is not there. If the app is there, it will be = opened, so this can't be used to silently test if an app is present, but = it does allow a native app to provide an alternative experience if an = app is not present. I don't think this works with custom schemes ... and = I don't know how it could work from a web app on the phone with the = current Safari APIs. >>=20 >> Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, = sms:, facetime: ? >>=20 >> [1] = https://developer.apple.com/documentation/xcode/allowing_apps_and_websites= _to_link_to_your_content/defining_a_custom_url_scheme_for_your_app = >>=20 >>=20 >> =E1=90=A7 >>=20 >> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones = > = wrote: >> You are - that is not standard which is opeind:// >> This is the one step that still needs to be optimized for SIOP to = have good UX. >> Peace ..tom >>=20 >>=20 >> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt > wrote: >> Hi Tom >>=20 >> I watched your video (I watched at 2X speed) >>=20 >> Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct? >>=20 >> /Dick=20 >> =E1=90=A7 >>=20 >> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones = > = wrote: >> Well, here's a demo. Note that in this case the AS is not online all = of the time, so it is really implicit flow and the OIDC id-token comes = from the siop device directly. >> (whether this is front-channel or back channel is no longer an = interesting question.) >> Now if an always-on AS is required, that is possible, but probably = beyond the scope of this effort and would require something like an = agent-in-the-sky (with diamonds). >> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 = >> Peace ..tom >>=20 >>=20 >> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer > wrote: >> Ultimately, in most situations like these in the real world, the = hurdle isn=E2=80=99t technical compatibility so much as it is trust = compatibility. The RP (client) needs to have some incentive to trust the = assertions and identity information that=E2=80=99s coming from the AS. = The same is true for an RS trusting tokens from the AS. The hard = question is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), = but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t = answer very well, because it=E2=80=99s a hard question). >>=20 >> Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of = it more than OAuth2/OIDC have by allowing the bootstrap of the process = from a starting call: the interaction and continuation URIs handed back = by the AS don=E2=80=99t need to be the same URIs that the client starts = with, so just like SIOP the process can start in HTTP and potentially = move to other communication channels. A major difference is that we = aren=E2=80=99t dependent on the assumption that the user will always be = in a browser at some stage, and so the whole raft of front-channel = messages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve= got an opportunity to more explicitly open up alternative communication = channels here, and that=E2=80=99s something I=E2=80=99d like to see = engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a = concrete proposal as to how that would work over specific protocols, = starting with what we=E2=80=99ve got today.=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault = > wrote: >>>=20 >>> Hi Denis, hi Francis,=20 >>>=20 >>> At some point integration with SSI (on the authentication side) will = probably occur, including amongst other possibilities SIOP (since they = work with OpenID a part of the work will probably be made easier).=20 >>>=20 >>> That being said, Denis is right. It's not an AS. Technically it's = entirely possible to rely on a decentralized wallet (for instance on = your phone) and a centralized AS. I know of a few studies on how to = decentralize the AS itself (for instance = https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02 = ). >>> Maybe it exists, but I'm still looking for real scenarios (or even = architectures) where an AS is deployed directly on a phone, and under = the sole authority of the RO, while being compatible with the rest of = the world.=20 >>>=20 >>> Cheers, >>> Fabien >>>=20 >>> On Tue, Nov 17, 2020 at 5:45 PM Denis > wrote: >>> Hello Francis, >>>=20 >>> See two comments in line. >>>=20 >>>>=20 >>>> B) Current Document >>>>=20 >>>> Roles description shall not hold any assumption on the physical = structure of the party fulfilling the roles. >>>> [FI] not sure what you mean >>>> [FP] for example, we assume the AS is a server! In most SSI based = use cases, the AS will be running on the user device. See SIOP = (https://identity.foundation/did-siop/ = ). >>> I browsed through the two drafts, i.e. : >>>=20 >>> Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, = and representations W3C Working Draft 08 November 2020 >>> Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft >>> At no place within these two documents, it is possible to imagine = that "the AS will be running on the user device". >>>=20 >>> =46rom section 3 of the DIF Working Group Draft: >>>=20 >>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], = the SIOP will not return an access token to the RP". >>>=20 >>> An Identity Wallet is not an AS.=20 >>>=20 >>>>=20 >>>> Roles:=20 >>>> -> grant endpoint of the AS: Why is this a post request? This = eliminates the chance of having user device hosted AS (no server). >>>> [FI] what would you propose instead? >>>> Would also be interested to understand better the deployment model = when there is no server. That's something that was discussed several = times but I'm still missing the underlying architecture and use case. >>>> [FP] See above (SIOP). There will be a lot of identity wallets = operated on end user device. >>> See the above comment. Please, do not confuse an Identity Wallet = with an Authentication Server (AS). >>>=20 >>> Denis >>>=20 >>>>=20 >>>> -> Resource Owner (RO) : Authorizes the request? Does it authorize = the request or the access to a resource? >>>> [FI] yes, we should make the wording clearer >>>>=20 >>>> Missing Section Interactions: >>>> --> This section shall introduce the notion of interaction before = we start listing interaction types. >>>> [FI] yes=20 >>>>=20 >>>> Interaction Types: >>>> --> I prefer a classification with Redirect, Decoupled and Embedded = is. In the draft, we have one redirect and 2 decouple interactions and = nothing else. >>>> [FI] this should be handled as a specific discussion item. As a = reminder, how would you define embedded? >>>>=20 >>>> In practice there's at least these modes: >>>> - redirect and redirect back >>>> - redirect to different browser or device >>>> - user code >>>> - CIBA >>>> [FP] This classification is limited. >>>> Redirect: same device, same or different user agents (browser, = mobile app, desktop app, ...) >>>> Decoupled: different devices >>>> Embedded : RC carries RO authorization to AS >>>>=20 >>>>=20 >>>> Resource Access Request vs. Resource Request >>>> --> Both are mixed up. No clarification of the context of each = section. >>>> [FI] could you clarify what you'd expect. Btw on this topic, = there's a more general discussion on whether we should make a = distinction or not.=20 >>>> =E2=80=8B[FP]: Here: >>>> Resource Access Request: Requesting Access to a resource. Response = is an access token (or any type of grant) >>>> Resource Request: Request the resource. Response is the resource = (or a corresponding execution) >>>>=20 >>>> Token Content Negotiation >>>> --> Not expressed as such. This is central to GNAP and not = represented enough in the document. >>>> [FI] right. This should be a specific discussion item.=20 >>>>=20 >>>> Requesting "User" Information >>>> we identify two types of users: RQ and RO. It will be better not to = refer to a user in this draft, but either to a RQ or an RO. >>>> [FI] yes that would avoid potential misunderstandings. Although in = the end, people will translate RQ into user or end-user most of the = time. Cf in definition, currently we have Requesting Party (RQ, aka = "user") >>>>=20 >>>>=20 >>>> Interaction Again >>>> -> For each interaction type, we will have to describe the protocol = flow and the nature and behavior of involved Roles (Parties), Elements, = Requests. >>>> [FI] yes =20 >>>>=20 >>>> [FP] Will these and into tickets? >>>>=20 >>>> Best regards. >>>> /Francis >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_48C4C212-7BF3-4DEB-9543-C1C8E445AA74 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Tom, = can you expand on how exactly the back-channel  communication works = between on-device components? Do you use HTTP locally?

Thanks,
 =E2=80= =94 Justin

On Feb 4, 2021, at 1:03 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

Justin's analysis of use of the = front channel is misleading.
It could equally be argued = that what i have done is installed an AS on the phone and the = communications with it & the PR is back channel.
Basically the point is that the old OIDC paradigms are no = longer valid.
Be the change you want to see in the world = ..tom


On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
Yes, = issue (#168) message based interaction / DIDComm is a tentative = alternative mecanism for the interaction part. Not sure how that would = work in details though, prototyping will probably help here.
Token delivery through continuation seems fine to me. = The client will probably have to wait for the next polling before it = receives a token issued as the result of an asynchronous interaction, = but that's not a big issue.

But the AS on the phone seems like a harder nut to crack, at = least at first sight. I think that would be awesome, but it gives me = headaches, so I think I'll work on easier stuff right now ;-)

Fabien  

On Thu, Feb 4, 2021 at 4:30 PM Justin = Richer <jricher@mit.edu> wrote:
One of the = biggest drawbacks of the current app-centric approaches in OIDC = (self-issued OP, or SIOP) is that they depend on using the front channel = and browser redirects to pass everything, which is something that GNAP = is deliberately getting away from by starting in the back channel.

That said, once a = request is kicked off in GNAP, the interaction and fulfillment can = happen through any number of means. Part of the work that=E2=80=99s = being done with the =E2=80=9Cinteraction=E2=80=9D section is going to = help facilitate this, and I think that there are some other potential = branches here.

Token delivery is where things get extra weird though =E2=80=94= we are explicitly not delivering tokens in the front channel in the = core of GNAP, we=E2=80=99re using the response from the continuation = API. One idea (that isn=E2=80=99t particularly well thought out and = hasn=E2=80=99t been implemented at all) is to have an extension declare = an alternative response from the =E2=80=9Ccontinue=E2=80=9D section = that=E2=80=99s defined today, which points to the GNPA continuation API. = If an extension defines some alternative way to deliver tokens, that = could live alongside a continuation API and the client could indicate = support for it in its initial request.

In any event, alternative interaction = and delivery methods are important, and even if we aren=E2=80=99t going = to support every last one of them directly, the protocol design should = at least be aware of them.

 =E2=80=94 Justin

On Feb = 4, 2021, at 8:35 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Tom, 

Sure, any experience on = that would be greatly appreciated, we're calling for help here (the = point being that I suspect what they're doing is not trivial).

Fabien

On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
I've had = such an app working for over a year. There are issues which are being = addressed by the browser Interaction team of oidc.

thx ..Tom (mobile)

On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi = Francis, 

I've = tried a few things with regards to using the AS on a phone, but it's = really quite complex. 

Making that run on a phone comes with = quite a bit of trouble. The most difficult part if that we'd need to use = a secure element, but just installing and hosting a http server securely = is not a standard setup at all. I suggest interested people step in to = work on this, as we already have a lot of work for the (more usual) = server case and already handle a privacy preserving = scheme. 

Please let us know what you think.

Cheers,
Fabien 

On Tue, Nov = 24, 2020 at 5:55 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,

I've thought a bit more to = what you said. I think I'll give it a try as a separate experiment (in = code, not in theory). Not that I would expect it to be included in GNAP, = but I kind of like the idea :-)

The direct impact for GNAP = would be to think about multiple ASs. 

Will let = you know. 

Fabien 


Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha = <fpo@adorsys.de> a =C3=A9crit :
It would be nice if the protocol was designed at many layers of = abstraction.

  • The first layer shall design abstract protocol flows, = without specification of the mode and mechanism of interaction.
  • The second layer can instantiate the first layer for = dedicated interaction. Here we can talk http, we can define interactions = that presume server based token generation, we can define interaction = that run on user device based token generation.
This is also the fundament of the structure I proposed = for the spec (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: = Fabien Imbault <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>; Dick Hardt <dick.hardt@gmail.com>; Tom Jones = <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer = <jricher@mit.edu>
Subject: Re: [GNAP] Review of = draft-ietf-gnap-core-protocol-00
 
Would make sense, but not so easy as we rely = heavily on HTTP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a = local sandbox on your phone, for your own AS), but it's really early = stage. This also poses another question that Denis has put forward, i.e. = how do we handle the multiple AS scenario (likely to occur then). 

Fabien 

On Wed, Nov 18, 2020 at 12:16 PM Francis = Pouatcha <fpo@adorsys.de> = wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that = subsumes that the "AS" is a "Server". Designing a new protocol, we = cannot afford this limitation.
  • I just mentioned SIOP = to show a known and closed example? Let us not focus on the device local = discovery scheme (like openid:) for now.
  • As = capability of holding private keys on user device evolves, server-based = issuing of token will be fading out giving way to device local = generation of token.
While designing GNAP, let us assume the AS-Role can be = exercised on a user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-bounces@ietf.org> on behalf = of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis = <denis.ietf@free.fr>; GNAP Mailing = List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of = draft-ietf-gnap-core-protocol-00
 
Got it. 

So web apps invoke a openid: deep link and hope there is = an app to handle the openid: scheme? ... and that it is the user's = wallet rather than some malware that has registered openid: on the = mobile device?

A native app can attempt to open a deep link associated = with an app, and will fail if the app is not there. If the app is there, = it will be opened, so this can't be used to silently test if an app is = present, but it does allow a native app to provide an alternative experience if an app is not present. I don't think this = works with custom schemes ... and I don't know how it could work from a = web app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but = perhaps they can be convinced to make openid: a managed scheme similar = to mailto:, tel:, sms:, facetime: ?

[1] https://developer.apple.com/documentation/xcode/allowing_apps_a= nd_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_= app


3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones = <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized = for SIOP to have good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt = <dick.hardt@gmail.com> = wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using = localhost:8765 to communicate with the wallet. Am I correct?

/Dick 
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones = <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case = the AS is not online all of the time, so it is really implicit flow and = the OIDC id-token comes from the siop device directly.
(whether this is front-channel or back channel is no = longer an interesting question.)
Now if an always-on AS is required, that is possible, = but probably beyond the scope of this effort and would require something = like an agent-in-the-sky (with diamonds).
here is the = link to the 9 min video   https://youtu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin = Richer <jricher@mit.edu> = wrote:
Ultimately, in most situations like these in the real = world, the hurdle isn=E2=80=99t technical compatibility so much as it is = trust compatibility. The RP (client) needs to have some incentive to = trust the assertions and identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The = hard question is less =E2=80=9Chow=E2=80=9D to do that (which SSI = answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80= =99t answer very well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to = support this =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got = the start of it more than OAuth2/OIDC have by allowing the bootstrap of = the process from a starting call: the interaction and continuation URIs = handed back by the AS don=E2=80=99t need to be the same URIs that the client starts = with, so just like SIOP the process can start in HTTP and potentially = move to other communication channels. A major difference is that we = aren=E2=80=99t dependent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel = messages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve= got an opportunity to more explicitly open up alternative communication = channels here, and that=E2=80=99s something I=E2=80=99d like to see = engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete = proposal as to how that would work over specific protocols, starting = with what we=E2=80=99ve got today. 

 =E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> = wrote:

Hi Denis, hi Francis, 

At some point integration with SSI (on the = authentication side) will probably occur, including amongst other = possibilities SIOP (since they work with OpenID a part of the work will = probably be made easier). 

That being said, Denis is right. It's not an AS. = Technically it's entirely possible to rely on a decentralized wallet = (for instance on your phone) and a centralized AS. I know of a few = studies on how to decentralize the AS itself (for instance https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-= 02).
Maybe it exists, but I'm still looking for real = scenarios (or even architectures) where an AS is deployed directly on a = phone, and under the sole authority of the RO, while being compatible = with the rest of the world. 

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
Hello  Francis,

See two comments in line.


B) Current Document

Roles description = shall not hold any assumption on the physical structure of the party = fulfilling the roles.
[FI] = not sure what you mean
 [FP] for example, we assume the AS is a server! In = most SSI based use cases, the AS will be running on the user device. See = SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, = data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile = v0.1. DIF Working Group Draft

At no place within = these two documents, it is possible to imagine that "the AS will be = running on the user device".

=46rom section 3 of the DIF Working Group Draft:

      "Unlike the OIDC Authorization = Code Flow as per [OIDC.Core], the SIOP will not return an access token = to the RP".

An Identity Wallet is not an AS.


Roles: 
-> grant endpoint of the AS: Why = is this a post request? This eliminates the chance of having user device = hosted AS (no server).
[FI] = what would you propose instead?
Would = also be interested to understand better the deployment model when there = is no server. That's something that was discussed several times but I'm = still missing the underlying architecture and use case.
 [FP] See above (SIOP). There will be a lot of identity = wallets operated on end user device.

See the above comment. Please, do not confuse = an Identity Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : = Authorizes the request? Does it authorize the request or the access to a = resource?
[FI] = yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce = the notion of interaction before we start listing interaction = types.
[FI] = yes 

Interaction Types:
--> I prefer a classification = with Redirect, Decoupled and Embedded is. In the draft, we have one = redirect and 2 decouple interactions and nothing else.
[FI] = this should be handled as a specific discussion item. As a reminder, how = would you define embedded?

In = practice there's at least these modes:
- = redirect and redirect back
- = redirect to different browser or device
- = user code
- = CIBA
[FP] This classification is = limited.
  • Redirect: same device, same or different user agents = (browser, mobile app, desktop app, ...)
  • Decoupled: = different devices
  • Embedded : RC carries RO = authorization to AS


Resource Access Request vs. = Resource Request
--> Both are mixed up. No = clarification of the context of each section.
[FI] = could you clarify what you'd expect.  Btw on this topic, there's a = more general discussion on whether we should make a distinction or = not. 
=E2=80=8B[FP]: = Here:
  • Resource Access Request: = Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request = the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This = is central to GNAP and not represented enough  in the = document.
[FI] = right. This should be a specific discussion item. 

Requesting "User" Information
we identify two types of users: RQ = and RO. It will be better not to refer to a user in this draft, but = either to a RQ or an RO.
[FI] = yes that would avoid potential misunderstandings. Although in the end, = people will translate RQ into user or end-user most of the time. Cf = in definition, currently we have Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we = will have to describe the protocol flow and the nature and behavior of = involved Roles (Parties), Elements, Requests.
[FI] = yes  

[FP] Will these and into tickets?

Best regards.
/Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_48C4C212-7BF3-4DEB-9543-C1C8E445AA74-- From nobody Thu Feb 4 11:18:10 2021 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 1D3C03A1742 for ; Thu, 4 Feb 2021 11:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, PDS_SHORTFWD_URISHRT_QP=1.498, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 vyAs8Xo1PILZ for ; Thu, 4 Feb 2021 11:18:04 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0B0C3A1740 for ; Thu, 4 Feb 2021 11:18:03 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 114JI0Ft023428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 4 Feb 2021 14:18:00 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DB628BFB-71A0-41B5-A06C-152E6BFCC6C6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 4 Feb 2021 14:18:00 -0500 In-Reply-To: Cc: txauth gnap To: Tom Jones References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> <77D1AE7B-076F-4095-8FAA-7C35D74614BD@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 19:18:08 -0000 --Apple-Mail=_DB628BFB-71A0-41B5-A06C-152E6BFCC6C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK, thanks =E2=80=94 in that case, there are no changes at all to GNAP, = which is already HTTP driven. The harder parts tend to be where you = can=E2=80=99t (or don=E2=80=99t want to) use something like that. =E2=80=94 Justin > On Feb 4, 2021, at 2:16 PM, Tom Jones = wrote: >=20 > yes, loopback >=20 > Be the change you want to see in the world ..tom >=20 >=20 > On Thu, Feb 4, 2021 at 11:01 AM Justin Richer > wrote: > Tom, can you expand on how exactly the back-channel communication = works between on-device components? Do you use HTTP locally? >=20 > Thanks, > =E2=80=94 Justin >=20 >> On Feb 4, 2021, at 1:03 PM, Tom Jones > wrote: >>=20 >> Justin's analysis of use of the front channel is misleading. >> It could equally be argued that what i have done is installed an AS = on the phone and the communications with it & the PR is back channel. >> Basically the point is that the old OIDC paradigms are no longer = valid. >> Be the change you want to see in the world ..tom >>=20 >>=20 >> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault = > wrote: >> Yes, issue (#168) message based interaction / DIDComm is a tentative = alternative mecanism for the interaction part. Not sure how that would = work in details though, prototyping will probably help here. >> Token delivery through continuation seems fine to me. The client will = probably have to wait for the next polling before it receives a token = issued as the result of an asynchronous interaction, but that's not a = big issue. >>=20 >> But the AS on the phone seems like a harder nut to crack, at least at = first sight. I think that would be awesome, but it gives me headaches, = so I think I'll work on easier stuff right now ;-) >>=20 >> Fabien =20 >>=20 >> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer > wrote: >> One of the biggest drawbacks of the current app-centric approaches in = OIDC (self-issued OP, or SIOP) is that they depend on using the front = channel and browser redirects to pass everything, which is something = that GNAP is deliberately getting away from by starting in the back = channel. >>=20 >> That said, once a request is kicked off in GNAP, the interaction and = fulfillment can happen through any number of means. Part of the work = that=E2=80=99s being done with the =E2=80=9Cinteraction=E2=80=9D section = is going to help facilitate this, and I think that there are some other = potential branches here. >>=20 >> Token delivery is where things get extra weird though =E2=80=94 we = are explicitly not delivering tokens in the front channel in the core of = GNAP, we=E2=80=99re using the response from the continuation API. One = idea (that isn=E2=80=99t particularly well thought out and hasn=E2=80=99t = been implemented at all) is to have an extension declare an alternative = response from the =E2=80=9Ccontinue=E2=80=9D section that=E2=80=99s = defined today, which points to the GNPA continuation API. If an = extension defines some alternative way to deliver tokens, that could = live alongside a continuation API and the client could indicate support = for it in its initial request. >>=20 >> In any event, alternative interaction and delivery methods are = important, and even if we aren=E2=80=99t going to support every last one = of them directly, the protocol design should at least be aware of them. >>=20 >> =E2=80=94 Justin >>=20 >>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault > wrote: >>>=20 >>> Hi Tom,=20 >>>=20 >>> Sure, any experience on that would be greatly appreciated, we're = calling for help here (the point being that I suspect what they're doing = is not trivial). >>>=20 >>> Fabien >>>=20 >>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones = > = wrote: >>> I've had such an app working for over a year. There are issues which = are being addressed by the browser Interaction team of oidc. >>>=20 >>> thx ..Tom (mobile) >>>=20 >>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault = > wrote: >>> Hi Francis,=20 >>>=20 >>> I've tried a few things with regards to using the AS on a phone, but = it's really quite complex.=20 >>>=20 >>> Making that run on a phone comes with quite a bit of trouble. The = most difficult part if that we'd need to use a secure element, but just = installing and hosting a http server securely is not a standard setup at = all. I suggest interested people step in to work on this, as we already = have a lot of work for the (more usual) server case and already handle a = privacy preserving scheme.=20 >>>=20 >>> Please let us know what you think. >>>=20 >>> Cheers, >>> Fabien=20 >>>=20 >>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault = > wrote: >>> Hi Francis, >>>=20 >>> I've thought a bit more to what you said. I think I'll give it a try = as a separate experiment (in code, not in theory). Not that I would = expect it to be included in GNAP, but I kind of like the idea :-) >>>=20 >>> The direct impact for GNAP would be to think about multiple ASs.=20 >>>=20 >>> Will let you know.=20 >>>=20 >>> Fabien=20 >>>=20 >>>=20 >>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha > a =C3=A9crit : >>> It would be nice if the protocol was designed at many layers of = abstraction. >>>=20 >>> The first layer shall design abstract protocol flows, without = specification of the mode and mechanism of interaction. >>> The second layer can instantiate the first layer for dedicated = interaction. Here we can talk http, we can define interactions that = presume server based token generation, we can define interaction that = run on user device based token generation. >>> This is also the fundament of the structure I proposed for the spec = (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30 = ). >>>=20 >>> /Francis >>>=20 >>> From: Fabien Imbault > >>> Sent: Wednesday, November 18, 2020 6:35 AM >>> To: Francis Pouatcha > >>> Cc: txauth@ietf.org >; Dick Hardt >; Tom Jones >; Denis >; Justin Richer > >>> Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>> =20 >>> Would make sense, but not so easy as we rely heavily on HTTP. Hence = the discussion about deep links and so on. >>>=20 >>> An alternative might be provided by wasm/wasi (running a local = sandbox on your phone, for your own AS), but it's really early stage. = This also poses another question that Denis has put forward, i.e. how do = we handle the multiple AS scenario (likely to occur then).=20 >>>=20 >>> Fabien=20 >>>=20 >>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha > wrote: >>> We are drifting away from the original problem space. >>> My original mention was about the "POST" request, that subsumes that = the "AS" is a "Server". Designing a new protocol, we cannot afford this = limitation. >>> I just mentioned SIOP to show a known and closed example? Let us not = focus on the device local discovery scheme (like openid:) for now. >>> As capability of holding private keys on user device evolves, = server-based issuing of token will be fading out giving way to device = local generation of token. >>> While designing GNAP, let us assume the AS-Role can be exercised on = a user device and design the protocol to honor that. >>>=20 >>> Best regards, >>> /Francis >>> From: TXAuth > on behalf of Dick Hardt = > >>> Sent: Tuesday, November 17, 2020 1:28 PM >>> To: Tom Jones > >>> Cc: Fabien Imbault >; Denis >; GNAP Mailing List >; Justin Richer > >>> Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>> =20 >>> Got it.=20 >>>=20 >>> So web apps invoke a openid: deep link and hope there is an app to = handle the openid: scheme? ... and that it is the user's wallet rather = than some malware that has registered openid: on the mobile device? >>>=20 >>> A native app can attempt to open a deep link associated with an app, = and will fail if the app is not there. If the app is there, it will be = opened, so this can't be used to silently test if an app is present, but = it does allow a native app to provide an alternative experience if an = app is not present. I don't think this works with custom schemes ... and = I don't know how it could work from a web app on the phone with the = current Safari APIs. >>>=20 >>> Apple warns against using custom schemes [1] ... but perhaps they = can be convinced to make openid: a managed scheme similar to mailto:, = tel:, sms:, facetime: ? >>>=20 >>> [1] = https://developer.apple.com/documentation/xcode/allowing_apps_and_websites= _to_link_to_your_content/defining_a_custom_url_scheme_for_your_app = >>>=20 >>>=20 >>> =E1=90=A7 >>>=20 >>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones = > = wrote: >>> You are - that is not standard which is opeind:// >>> This is the one step that still needs to be optimized for SIOP to = have good UX. >>> Peace ..tom >>>=20 >>>=20 >>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt > wrote: >>> Hi Tom >>>=20 >>> I watched your video (I watched at 2X speed) >>>=20 >>> Looks like the employment website app that is using localhost:8765 = to communicate with the wallet. Am I correct? >>>=20 >>> /Dick=20 >>> =E1=90=A7 >>>=20 >>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones = > = wrote: >>> Well, here's a demo. Note that in this case the AS is not online all = of the time, so it is really implicit flow and the OIDC id-token comes = from the siop device directly. >>> (whether this is front-channel or back channel is no longer an = interesting question.) >>> Now if an always-on AS is required, that is possible, but probably = beyond the scope of this effort and would require something like an = agent-in-the-sky (with diamonds). >>> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 = >>> Peace ..tom >>>=20 >>>=20 >>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer > wrote: >>> Ultimately, in most situations like these in the real world, the = hurdle isn=E2=80=99t technical compatibility so much as it is trust = compatibility. The RP (client) needs to have some incentive to trust the = assertions and identity information that=E2=80=99s coming from the AS. = The same is true for an RS trusting tokens from the AS. The hard = question is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), = but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t = answer very well, because it=E2=80=99s a hard question). >>>=20 >>> Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of = it more than OAuth2/OIDC have by allowing the bootstrap of the process = from a starting call: the interaction and continuation URIs handed back = by the AS don=E2=80=99t need to be the same URIs that the client starts = with, so just like SIOP the process can start in HTTP and potentially = move to other communication channels. A major difference is that we = aren=E2=80=99t dependent on the assumption that the user will always be = in a browser at some stage, and so the whole raft of front-channel = messages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve= got an opportunity to more explicitly open up alternative communication = channels here, and that=E2=80=99s something I=E2=80=99d like to see = engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a = concrete proposal as to how that would work over specific protocols, = starting with what we=E2=80=99ve got today.=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault = > wrote: >>>>=20 >>>> Hi Denis, hi Francis,=20 >>>>=20 >>>> At some point integration with SSI (on the authentication side) = will probably occur, including amongst other possibilities SIOP (since = they work with OpenID a part of the work will probably be made easier).=20= >>>>=20 >>>> That being said, Denis is right. It's not an AS. Technically it's = entirely possible to rely on a decentralized wallet (for instance on = your phone) and a centralized AS. I know of a few studies on how to = decentralize the AS itself (for instance = https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02 = ). >>>> Maybe it exists, but I'm still looking for real scenarios (or even = architectures) where an AS is deployed directly on a phone, and under = the sole authority of the RO, while being compatible with the rest of = the world.=20 >>>>=20 >>>> Cheers, >>>> Fabien >>>>=20 >>>> On Tue, Nov 17, 2020 at 5:45 PM Denis > wrote: >>>> Hello Francis, >>>>=20 >>>> See two comments in line. >>>>=20 >>>>>=20 >>>>> B) Current Document >>>>>=20 >>>>> Roles description shall not hold any assumption on the physical = structure of the party fulfilling the roles. >>>>> [FI] not sure what you mean >>>>> [FP] for example, we assume the AS is a server! In most SSI based = use cases, the AS will be running on the user device. See SIOP = (https://identity.foundation/did-siop/ = ). >>>> I browsed through the two drafts, i.e. : >>>>=20 >>>> Decentralized Identifiers (DIDs) v1.0 Core architecture, data = model, and representations W3C Working Draft 08 November 2020 >>>> Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft >>>> At no place within these two documents, it is possible to imagine = that "the AS will be running on the user device". >>>>=20 >>>> =46rom section 3 of the DIF Working Group Draft: >>>>=20 >>>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], = the SIOP will not return an access token to the RP". >>>>=20 >>>> An Identity Wallet is not an AS.=20 >>>>=20 >>>>>=20 >>>>> Roles:=20 >>>>> -> grant endpoint of the AS: Why is this a post request? This = eliminates the chance of having user device hosted AS (no server). >>>>> [FI] what would you propose instead? >>>>> Would also be interested to understand better the deployment model = when there is no server. That's something that was discussed several = times but I'm still missing the underlying architecture and use case. >>>>> [FP] See above (SIOP). There will be a lot of identity wallets = operated on end user device. >>>> See the above comment. Please, do not confuse an Identity Wallet = with an Authentication Server (AS). >>>>=20 >>>> Denis >>>>=20 >>>>>=20 >>>>> -> Resource Owner (RO) : Authorizes the request? Does it authorize = the request or the access to a resource? >>>>> [FI] yes, we should make the wording clearer >>>>>=20 >>>>> Missing Section Interactions: >>>>> --> This section shall introduce the notion of interaction before = we start listing interaction types. >>>>> [FI] yes=20 >>>>>=20 >>>>> Interaction Types: >>>>> --> I prefer a classification with Redirect, Decoupled and = Embedded is. In the draft, we have one redirect and 2 decouple = interactions and nothing else. >>>>> [FI] this should be handled as a specific discussion item. As a = reminder, how would you define embedded? >>>>>=20 >>>>> In practice there's at least these modes: >>>>> - redirect and redirect back >>>>> - redirect to different browser or device >>>>> - user code >>>>> - CIBA >>>>> [FP] This classification is limited. >>>>> Redirect: same device, same or different user agents (browser, = mobile app, desktop app, ...) >>>>> Decoupled: different devices >>>>> Embedded : RC carries RO authorization to AS >>>>>=20 >>>>>=20 >>>>> Resource Access Request vs. Resource Request >>>>> --> Both are mixed up. No clarification of the context of each = section. >>>>> [FI] could you clarify what you'd expect. Btw on this topic, = there's a more general discussion on whether we should make a = distinction or not.=20 >>>>> =E2=80=8B[FP]: Here: >>>>> Resource Access Request: Requesting Access to a resource. Response = is an access token (or any type of grant) >>>>> Resource Request: Request the resource. Response is the resource = (or a corresponding execution) >>>>>=20 >>>>> Token Content Negotiation >>>>> --> Not expressed as such. This is central to GNAP and not = represented enough in the document. >>>>> [FI] right. This should be a specific discussion item.=20 >>>>>=20 >>>>> Requesting "User" Information >>>>> we identify two types of users: RQ and RO. It will be better not = to refer to a user in this draft, but either to a RQ or an RO. >>>>> [FI] yes that would avoid potential misunderstandings. Although in = the end, people will translate RQ into user or end-user most of the = time. Cf in definition, currently we have Requesting Party (RQ, aka = "user") >>>>>=20 >>>>>=20 >>>>> Interaction Again >>>>> -> For each interaction type, we will have to describe the = protocol flow and the nature and behavior of involved Roles (Parties), = Elements, Requests. >>>>> [FI] yes =20 >>>>>=20 >>>>> [FP] Will these and into tickets? >>>>>=20 >>>>> Best regards. >>>>> /Francis >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 --Apple-Mail=_DB628BFB-71A0-41B5-A06C-152E6BFCC6C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OK, = thanks =E2=80=94 in that case, there are no changes at all to GNAP, = which is already HTTP driven. The harder parts tend to be where you = can=E2=80=99t (or don=E2=80=99t want to) use something like that.

 =E2=80=94 = Justin

On Feb 4, 2021, at 2:16 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

yes, = loopback

Be the = change you want to see in the world = ..tom


On Thu, Feb 4, 2021 at 11:01 AM Justin Richer = <jricher@mit.edu> = wrote:
Tom, can you expand on how exactly the = back-channel  communication works between on-device components? Do = you use HTTP locally?

Thanks,
 =E2=80=94 Justin

On Feb 4, 2021, at 1:03 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

Justin's analysis = of use of the front channel is misleading.
It could = equally be argued that what i have done is installed an AS on the phone = and the communications with it & the PR is back channel.
Basically the point is that the old OIDC paradigms are no = longer valid.
Be the change you want to see in the world = ..tom


On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
Yes, = issue (#168) message based interaction / DIDComm is a tentative = alternative mecanism for the interaction part. Not sure how that would = work in details though, prototyping will probably help here.
Token delivery through continuation seems fine to me. = The client will probably have to wait for the next polling before it = receives a token issued as the result of an asynchronous interaction, = but that's not a big issue.

But the AS on the phone seems like a harder nut to crack, at = least at first sight. I think that would be awesome, but it gives me = headaches, so I think I'll work on easier stuff right now ;-)

Fabien  

On Thu, Feb 4, 2021 at 4:30 PM Justin = Richer <jricher@mit.edu> wrote:
One of the = biggest drawbacks of the current app-centric approaches in OIDC = (self-issued OP, or SIOP) is that they depend on using the front channel = and browser redirects to pass everything, which is something that GNAP = is deliberately getting away from by starting in the back channel.

That said, once a = request is kicked off in GNAP, the interaction and fulfillment can = happen through any number of means. Part of the work that=E2=80=99s = being done with the =E2=80=9Cinteraction=E2=80=9D section is going to = help facilitate this, and I think that there are some other potential = branches here.

Token delivery is where things get extra weird though =E2=80=94= we are explicitly not delivering tokens in the front channel in the = core of GNAP, we=E2=80=99re using the response from the continuation = API. One idea (that isn=E2=80=99t particularly well thought out and = hasn=E2=80=99t been implemented at all) is to have an extension declare = an alternative response from the =E2=80=9Ccontinue=E2=80=9D section = that=E2=80=99s defined today, which points to the GNPA continuation API. = If an extension defines some alternative way to deliver tokens, that = could live alongside a continuation API and the client could indicate = support for it in its initial request.

In any event, alternative interaction = and delivery methods are important, and even if we aren=E2=80=99t going = to support every last one of them directly, the protocol design should = at least be aware of them.

 =E2=80=94 Justin

On Feb = 4, 2021, at 8:35 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Tom, 

Sure, any experience on = that would be greatly appreciated, we're calling for help here (the = point being that I suspect what they're doing is not trivial).

Fabien

On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
I've had = such an app working for over a year. There are issues which are being = addressed by the browser Interaction team of oidc.

thx ..Tom (mobile)

On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi = Francis, 

I've = tried a few things with regards to using the AS on a phone, but it's = really quite complex. 

Making that run on a phone comes with = quite a bit of trouble. The most difficult part if that we'd need to use = a secure element, but just installing and hosting a http server securely = is not a standard setup at all. I suggest interested people step in to = work on this, as we already have a lot of work for the (more usual) = server case and already handle a privacy preserving = scheme. 

Please let us know what you think.

Cheers,
Fabien 

On Tue, Nov = 24, 2020 at 5:55 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,

I've thought a bit more to = what you said. I think I'll give it a try as a separate experiment (in = code, not in theory). Not that I would expect it to be included in GNAP, = but I kind of like the idea :-)

The direct impact for GNAP = would be to think about multiple ASs. 

Will let = you know. 

Fabien 


Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha = <fpo@adorsys.de> a =C3=A9crit :
It would be nice if the protocol was designed at many layers of = abstraction.

  • The first layer shall design abstract protocol flows, = without specification of the mode and mechanism of interaction.
  • The second layer can instantiate the first layer for = dedicated interaction. Here we can talk http, we can define interactions = that presume server based token generation, we can define interaction = that run on user device based token generation.
This is also the fundament of the structure I proposed = for the spec (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>; Dick Hardt <dick.hardt@gmail.com>; Tom Jones = <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer = <jricher@mit.edu>
Subject: Re: [GNAP] Review of = draft-ietf-gnap-core-protocol-00
 
Would make sense, but not so easy as we rely = heavily on HTTP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a = local sandbox on your phone, for your own AS), but it's really early = stage. This also poses another question that Denis has put forward, i.e. = how do we handle the multiple AS scenario (likely to occur then). 

Fabien 

On Wed, Nov 18, 2020 at 12:16 PM Francis = Pouatcha <fpo@adorsys.de> = wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that = subsumes that the "AS" is a "Server". Designing a new protocol, we = cannot afford this limitation.
  • I just mentioned SIOP = to show a known and closed example? Let us not focus on the device local = discovery scheme (like openid:) for now.
  • As = capability of holding private keys on user device evolves, server-based = issuing of token will be fading out giving way to device local = generation of token.
While designing GNAP, let us assume the AS-Role can be = exercised on a user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth = <txauth-bounces@ietf.org> = on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis = <denis.ietf@free.fr>; GNAP Mailing = List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of = draft-ietf-gnap-core-protocol-00
 
Got it. 

So web apps invoke a openid: deep link and hope there is = an app to handle the openid: scheme? ... and that it is the user's = wallet rather than some malware that has registered openid: on the = mobile device?

A native app can attempt to open a deep link associated = with an app, and will fail if the app is not there. If the app is there, = it will be opened, so this can't be used to silently test if an app is = present, but it does allow a native app to provide an alternative experience if an app is not present. I don't think this = works with custom schemes ... and I don't know how it could work from a = web app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but = perhaps they can be convinced to make openid: a managed scheme similar = to mailto:, tel:, sms:, facetime: ?

[1] https://developer.apple.com/documentation/xcode/allowing_apps_a= nd_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_= app


3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones = <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized = for SIOP to have good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt = <dick.hardt@gmail.com> = wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using = localhost:8765 to communicate with the wallet. Am I correct?

/Dick 
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones = <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case = the AS is not online all of the time, so it is really implicit flow and = the OIDC id-token comes from the siop device directly.
(whether this is front-channel or back channel is no = longer an interesting question.)
Now if an always-on AS is required, that is possible, = but probably beyond the scope of this effort and would require something = like an agent-in-the-sky (with diamonds).
here is the = link to the 9 min video   https://youtu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin = Richer <jricher@mit.edu> = wrote:
Ultimately, in most situations like these in the real = world, the hurdle isn=E2=80=99t technical compatibility so much as it is = trust compatibility. The RP (client) needs to have some incentive to = trust the assertions and identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The = hard question is less =E2=80=9Chow=E2=80=9D to do that (which SSI = answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80= =99t answer very well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to = support this =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got = the start of it more than OAuth2/OIDC have by allowing the bootstrap of = the process from a starting call: the interaction and continuation URIs = handed back by the AS don=E2=80=99t need to be the same URIs that the client starts = with, so just like SIOP the process can start in HTTP and potentially = move to other communication channels. A major difference is that we = aren=E2=80=99t dependent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel = messages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve= got an opportunity to more explicitly open up alternative communication = channels here, and that=E2=80=99s something I=E2=80=99d like to see = engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete = proposal as to how that would work over specific protocols, starting = with what we=E2=80=99ve got today. 

 =E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> = wrote:

Hi Denis, hi Francis, 

At some point integration with SSI (on the = authentication side) will probably occur, including amongst other = possibilities SIOP (since they work with OpenID a part of the work will = probably be made easier). 

That being said, Denis is right. It's not an AS. = Technically it's entirely possible to rely on a decentralized wallet = (for instance on your phone) and a centralized AS. I know of a few = studies on how to decentralize the AS itself (for instance https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-= 02).
Maybe it exists, but I'm still looking for real = scenarios (or even architectures) where an AS is deployed directly on a = phone, and under the sole authority of the RO, while being compatible = with the rest of the world. 

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
Hello  Francis,

See two comments in line.


B) Current Document

Roles description = shall not hold any assumption on the physical structure of the party = fulfilling the roles.
[FI] = not sure what you mean
 [FP] for example, we assume the AS is a server! In = most SSI based use cases, the AS will be running on the user device. See = SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, = data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile = v0.1. DIF Working Group Draft

At no place within = these two documents, it is possible to imagine that "the AS will be = running on the user device".

=46rom section 3 of the DIF Working Group Draft:

      "Unlike the OIDC Authorization = Code Flow as per [OIDC.Core], the SIOP will not return an access token = to the RP".

An Identity Wallet is not an AS.


Roles: 
-> grant endpoint of the AS: Why = is this a post request? This eliminates the chance of having user device = hosted AS (no server).
[FI] = what would you propose instead?
Would = also be interested to understand better the deployment model when there = is no server. That's something that was discussed several times but I'm = still missing the underlying architecture and use case.
 [FP] See above (SIOP). There will be a lot of identity = wallets operated on end user device.

See the above comment. Please, do not confuse = an Identity Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : = Authorizes the request? Does it authorize the request or the access to a = resource?
[FI] = yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce = the notion of interaction before we start listing interaction = types.
[FI] = yes 

Interaction Types:
--> I prefer a classification = with Redirect, Decoupled and Embedded is. In the draft, we have one = redirect and 2 decouple interactions and nothing else.
[FI] = this should be handled as a specific discussion item. As a reminder, how = would you define embedded?

In = practice there's at least these modes:
- = redirect and redirect back
- = redirect to different browser or device
- = user code
- = CIBA
[FP] This classification is = limited.
  • Redirect: same device, same or different user agents = (browser, mobile app, desktop app, ...)
  • Decoupled: = different devices
  • Embedded : RC carries RO = authorization to AS


Resource Access Request vs. = Resource Request
--> Both are mixed up. No = clarification of the context of each section.
[FI] = could you clarify what you'd expect.  Btw on this topic, there's a = more general discussion on whether we should make a distinction or = not. 
=E2=80=8B[FP]: = Here:
  • Resource Access Request: = Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request = the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This = is central to GNAP and not represented enough  in the = document.
[FI] = right. This should be a specific discussion item. 

Requesting "User" Information
we identify two types of users: RQ = and RO. It will be better not to refer to a user in this draft, but = either to a RQ or an RO.
[FI] = yes that would avoid potential misunderstandings. Although in the end, = people will translate RQ into user or end-user most of the time. Cf = in definition, currently we have Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we = will have to describe the protocol flow and the nature and behavior of = involved Roles (Parties), Elements, Requests.
[FI] = yes  

[FP] Will these and into tickets?

Best regards.
/Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


= --Apple-Mail=_DB628BFB-71A0-41B5-A06C-152E6BFCC6C6-- From nobody Thu Feb 4 11:19:58 2021 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 1AF463A16F2 for ; Thu, 4 Feb 2021 11:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 Pga1dLmICxzg for ; Thu, 4 Feb 2021 11:19:48 -0800 (PST) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 3E70B3A1742 for ; Thu, 4 Feb 2021 11:19:38 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id o12so4485880ote.12 for ; Thu, 04 Feb 2021 11:19:38 -0800 (PST) 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=fQGWYwVjQhEhb3VWMVU7affi9d4nYOJ91dMbo5Jjrdw=; b=GR3c2/JrwDJhuZ4mogzhohlx/XsSGe4RJp9ww+X4dkF/fup4Tg++/fj+X8Au8TeZCM J5M6syjY/s+XJ8oOsuicIB1IrJzSGCXsMKqYqgwZCPTqtFs6/QSCnpaooanX9ROu280S Fw/DRKXCawQ7XguzW/Ldww33f68NfCi6apDdKyX1TZxfDMeUcnQUw01QtMpm4k2j18Qf 75p/7iUEiOARBOV6ct1ehTrJUaVdWLooz/8UpbSnmArwquDj97/GyFRBo4gQkirkmosU 8BanBBROG2oRVbOQuObWDN5KPMCL0DrXNXiXjBSz78i9CA8l80J85bkDgB2pUJiRy/zR NVDQ== 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=fQGWYwVjQhEhb3VWMVU7affi9d4nYOJ91dMbo5Jjrdw=; b=IkIUNithG0IhWg3jnnkRLNGMzM1N86dpfFqasB7pHixfJXA0H/Eo+nJ7xN0s8Ylkh4 c4g6cGZZ2kBfXjKKOMbRQjMYYcEW7PvtW6+YSetMARrkIx5jONngty6Z2y8c5O9CI0Wd ++82tsclZIGhWr+iOQANzHwoTY4fnH8FG946U8EafZx/xvF2l/O0v24FyW1JCbnCWPCJ OynFQX2a47qciWspCyfzO3TkQT59C57W0YQNsW5WjVX5nD8aFORJvJdGUXI1mLoadOLf /t1SpJ/GXJOl48EBMEtObdoqkKQU5PUj3iqsPDUVUShU4sjVfaA4wTX+9le6Bebvd+Pg SKlw== X-Gm-Message-State: AOAM532YYpBmx7TFbRRIz65EOH+eXBaMZbNvScGxIeqtnFhh4TRD/OOD 3eRhRqRBSVpmhIEijb+wKfB7FePLcuNrM8qBl2Y= X-Google-Smtp-Source: ABdhPJzx+gfADSs+xAwqd8+Bsertzp/nX8db1cTb4dMpP/Dezf4pRp3E5o8ggNPOk5uLbt/6unY30VrBHOp0tsBFSaQ= X-Received: by 2002:a05:6830:18c4:: with SMTP id v4mr685624ote.358.1612466377254; Thu, 04 Feb 2021 11:19:37 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> <77D1AE7B-076F-4095-8FAA-7C35D74614BD@mit.edu> In-Reply-To: From: Tom Jones Date: Thu, 4 Feb 2021 11:19:25 -0800 Message-ID: To: Justin Richer Cc: txauth gnap Content-Type: multipart/alternative; boundary="000000000000a0e93205ba8795ca" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 19:19:57 -0000 --000000000000a0e93205ba8795ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable doesn't work very well on windows uwp. works fine on smartphones Be the change you want to see in the world ..tom On Thu, Feb 4, 2021 at 11:18 AM Justin Richer wrote: > OK, thanks =E2=80=94 in that case, there are no changes at all to GNAP, w= hich is > already HTTP driven. The harder parts tend to be where you can=E2=80=99t = (or don=E2=80=99t > want to) use something like that. > > =E2=80=94 Justin > > On Feb 4, 2021, at 2:16 PM, Tom Jones > wrote: > > yes, loopback > > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 11:01 AM Justin Richer wrote: > >> Tom, can you expand on how exactly the back-channel communication works >> between on-device components? Do you use HTTP locally? >> >> Thanks, >> =E2=80=94 Justin >> >> On Feb 4, 2021, at 1:03 PM, Tom Jones >> wrote: >> >> Justin's analysis of use of the front channel is misleading. >> It could equally be argued that what i have done is installed an AS on >> the phone and the communications with it & the PR is back channel. >> Basically the point is that the old OIDC paradigms are no longer valid. >> Be the change you want to see in the world ..tom >> >> >> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault >> wrote: >> >>> Yes, issue (#168) message based interaction / DIDComm is a tentative >>> alternative mecanism for the interaction part. Not sure how that would = work >>> in details though, prototyping will probably help here. >>> Token delivery through continuation seems fine to me. The client will >>> probably have to wait for the next polling before it receives a token >>> issued as the result of an asynchronous interaction, but that's not a b= ig >>> issue. >>> >>> But the AS on the phone seems like a harder nut to crack, at least at >>> first sight. I think that would be awesome, but it gives me headaches, = so I >>> think I'll work on easier stuff right now ;-) >>> >>> Fabien >>> >>> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer wrote: >>> >>>> One of the biggest drawbacks of the current app-centric approaches in >>>> OIDC (self-issued OP, or SIOP) is that they depend on using the front >>>> channel and browser redirects to pass everything, which is something t= hat >>>> GNAP is deliberately getting away from by starting in the back channel= . >>>> >>>> That said, once a request is kicked off in GNAP, the interaction and >>>> fulfillment can happen through any number of means. Part of the work t= hat=E2=80=99s >>>> being done with the =E2=80=9Cinteraction=E2=80=9D section is going to = help facilitate this, >>>> and I think that there are some other potential branches here. >>>> >>>> Token delivery is where things get extra weird though =E2=80=94 we are >>>> explicitly not delivering tokens in the front channel in the core of G= NAP, >>>> we=E2=80=99re using the response from the continuation API. One idea (= that isn=E2=80=99t >>>> particularly well thought out and hasn=E2=80=99t been implemented at a= ll) is to >>>> have an extension declare an alternative response from the =E2=80=9Cco= ntinue=E2=80=9D >>>> section that=E2=80=99s defined today, which points to the GNPA continu= ation API. If >>>> an extension defines some alternative way to deliver tokens, that coul= d >>>> live alongside a continuation API and the client could indicate suppor= t for >>>> it in its initial request. >>>> >>>> In any event, alternative interaction and delivery methods are >>>> important, and even if we aren=E2=80=99t going to support every last o= ne of them >>>> directly, the protocol design should at least be aware of them. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault >>>> wrote: >>>> >>>> Hi Tom, >>>> >>>> Sure, any experience on that would be greatly appreciated, we're >>>> calling for help here (the point being that I suspect what they're doi= ng is >>>> not trivial). >>>> >>>> Fabien >>>> >>>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones >>>> wrote: >>>> >>>>> I've had such an app working for over a year. There are issues which >>>>> are being addressed by the browser Interaction team of oidc. >>>>> >>>>> thx ..Tom (mobile) >>>>> >>>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault >>>>> wrote: >>>>> >>>>>> Hi Francis, >>>>>> >>>>>> I've tried a few things with regards to using the AS on a phone, but >>>>>> it's really quite complex. >>>>>> >>>>>> Making that run on a phone comes with quite a bit of trouble. The >>>>>> most difficult part if that we'd need to use a secure element, but j= ust >>>>>> installing and hosting a http server securely is not a standard setu= p at >>>>>> all. I suggest interested people step in to work on this, as we alre= ady >>>>>> have a lot of work for the (more usual) server case and already hand= le a >>>>>> privacy preserving scheme. >>>>>> >>>>>> Please let us know what you think. >>>>>> >>>>>> Cheers, >>>>>> Fabien >>>>>> >>>>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Hi Francis, >>>>>>> >>>>>>> I've thought a bit more to what you said. I think I'll give it a tr= y >>>>>>> as a separate experiment (in code, not in theory). Not that I would= expect >>>>>>> it to be included in GNAP, but I kind of like the idea :-) >>>>>>> >>>>>>> The direct impact for GNAP would be to think about multiple ASs. >>>>>>> >>>>>>> Will let you know. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha a >>>>>>> =C3=A9crit : >>>>>>> >>>>>>>> It would be nice if the protocol was designed at many layers of >>>>>>>> abstraction. >>>>>>>> >>>>>>>> >>>>>>>> - The first layer shall design abstract protocol flows, without >>>>>>>> specification of the mode and mechanism of interaction. >>>>>>>> - The second layer can instantiate the first layer for >>>>>>>> dedicated interaction. Here we can talk http, we can define int= eractions >>>>>>>> that presume server based token generation, we can define inter= action that >>>>>>>> run on user device based token generation. >>>>>>>> >>>>>>>> This is also the fundament of the structure I proposed for the spe= c >>>>>>>> (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). >>>>>>>> >>>>>>>> /Francis >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> *From:* Fabien Imbault >>>>>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>>>>>> *To:* Francis Pouatcha >>>>>>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>>>>>> dick.hardt@gmail.com>; Tom Jones ; >>>>>>>> Denis ; Justin Richer >>>>>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>>>>> >>>>>>>> Would make sense, but not so easy as we rely heavily on HTTP. Henc= e >>>>>>>> the discussion about deep links and so on. >>>>>>>> >>>>>>>> An alternative might be provided by wasm/wasi (running a local >>>>>>>> sandbox on your phone, for your own AS), but it's really early sta= ge. This >>>>>>>> also poses another question that Denis has put forward, i.e. how d= o we >>>>>>>> handle the multiple AS scenario (likely to occur then). >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha >>>>>>>> wrote: >>>>>>>> >>>>>>>> We are drifting away from the original problem space. >>>>>>>> >>>>>>>> - My original mention was about the "POST" request, that >>>>>>>> subsumes that the "AS" is a "Server". Designing a new protocol,= we cannot >>>>>>>> afford this limitation. >>>>>>>> - I just mentioned SIOP to show a known and closed example? Let >>>>>>>> us not focus on the device local discovery scheme (like openid:= ) for now. >>>>>>>> - As capability of holding private keys on user device evolves, >>>>>>>> server-based issuing of token will be fading out giving way to = device local >>>>>>>> generation of token. >>>>>>>> >>>>>>>> While designing GNAP, let us assume the AS-Role can be exercised o= n >>>>>>>> a user device and design the protocol to honor that. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> /Francis >>>>>>>> ------------------------------ >>>>>>>> *From:* TXAuth on behalf of Dick Hardt < >>>>>>>> dick.hardt@gmail.com> >>>>>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>>>>>> *To:* Tom Jones >>>>>>>> *Cc:* Fabien Imbault ; Denis < >>>>>>>> denis.ietf@free.fr>; GNAP Mailing List ; Justin >>>>>>>> Richer >>>>>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>>>>> >>>>>>>> Got it. >>>>>>>> >>>>>>>> So web apps invoke a openid: deep link and hope there is an app to >>>>>>>> handle the openid: scheme? ... and that it is the user's wallet ra= ther than >>>>>>>> some malware that has registered openid: on the mobile device? >>>>>>>> >>>>>>>> A native app can attempt to open a deep link associated with an >>>>>>>> app, and will fail if the app is not there. If the app is there, i= t will be >>>>>>>> opened, so this can't be used to silently test if an app is presen= t, but it >>>>>>>> does allow a native app to provide an alternative experience if an= app is >>>>>>>> not present. I don't think this works with custom schemes ... and = I don't >>>>>>>> know how it could work from a web app on the phone with the curren= t Safari >>>>>>>> APIs. >>>>>>>> >>>>>>>> Apple warns against using custom schemes [1] ... but perhaps they >>>>>>>> can be convinced to make openid: a managed scheme similar to mailt= o:, >>>>>>>> tel:, sms:, facetime: ? >>>>>>>> >>>>>>>> [1] >>>>>>>> https://developer.apple.com/documentation/xcode/allowing_apps_and_= websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app >>>>>>>> >>>>>>>> >>>>>>>> =E1=90=A7 >>>>>>>> >>>>>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>> >>>>>>>> You are - that is not standard which is opeind:// >>>>>>>> This is the one step that still needs to be optimized for SIOP to >>>>>>>> have good UX. >>>>>>>> Peace ..tom >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Tom >>>>>>>> >>>>>>>> I watched your video (I watched at 2X speed) >>>>>>>> >>>>>>>> Looks like the employment website app that is using localhost:8765 >>>>>>>> to communicate with the wallet. Am I correct? >>>>>>>> >>>>>>>> /Dick >>>>>>>> =E1=90=A7 >>>>>>>> >>>>>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones < >>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>> >>>>>>>> Well, here's a demo. Note that in this case the AS is not online >>>>>>>> all of the time, so it is really implicit flow and the OIDC id-tok= en comes >>>>>>>> from the siop device directly. >>>>>>>> (whether this is front-channel or back channel is no longer an >>>>>>>> interesting question.) >>>>>>>> Now if an always-on AS is required, that is possible, but probably >>>>>>>> beyond the scope of this effort and would require something like a= n >>>>>>>> agent-in-the-sky (with diamonds). >>>>>>>> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 >>>>>>>> >>>>>>>> Peace ..tom >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>> Ultimately, in most situations like these in the real world, the >>>>>>>> hurdle isn=E2=80=99t technical compatibility so much as it is trus= t compatibility. >>>>>>>> The RP (client) needs to have some incentive to trust the assertio= ns and >>>>>>>> identity information that=E2=80=99s coming from the AS. The same i= s true for an RS >>>>>>>> trusting tokens from the AS. The hard question is less =E2=80=9Cho= w=E2=80=9D to do that >>>>>>>> (which SSI answers), but more =E2=80=9Cwhy=E2=80=9D to do that (wh= ich SSI doesn=E2=80=99t answer >>>>>>>> very well, because it=E2=80=99s a hard question). >>>>>>>> >>>>>>>> Still: it=E2=80=99s definitely a question about how to support thi= s =E2=80=9CAS on >>>>>>>> device=E2=80=9D element. We=E2=80=99ve got the start of it more th= an OAuth2/OIDC have by >>>>>>>> allowing the bootstrap of the process from a starting call: the in= teraction >>>>>>>> and continuation URIs handed back by the AS don=E2=80=99t need to = be the same URIs >>>>>>>> that the client starts with, so just like SIOP the process can sta= rt in >>>>>>>> HTTP and potentially move to other communication channels. A major >>>>>>>> difference is that we aren=E2=80=99t dependent on the assumption t= hat the user will >>>>>>>> always be in a browser at some stage, and so the whole raft of >>>>>>>> front-channel messages that SIOP relies on doesn=E2=80=99t fly. Th= at said, we=E2=80=99ve >>>>>>>> got an opportunity to more explicitly open up alternative communic= ation >>>>>>>> channels here, and that=E2=80=99s something I=E2=80=99d like to se= e engineered, even if >>>>>>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would >>>>>>>> work over specific protocols, starting with what we=E2=80=99ve got= today. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>> Hi Denis, hi Francis, >>>>>>>> >>>>>>>> At some point integration with SSI (on the authentication side) >>>>>>>> will probably occur, including amongst other possibilities SIOP (s= ince they >>>>>>>> work with OpenID a part of the work will probably be made easier). >>>>>>>> >>>>>>>> That being said, Denis is right. It's not an AS. Technically it's >>>>>>>> entirely possible to rely on a decentralized wallet (for instance = on your >>>>>>>> phone) and a centralized AS. I know of a few studies on how to dec= entralize >>>>>>>> the AS itself (for instance >>>>>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02)= . >>>>>>>> Maybe it exists, but I'm still looking for real scenarios (or even >>>>>>>> architectures) where an AS is deployed directly on a phone, and un= der the >>>>>>>> sole authority of the RO, while being compatible with the rest of = the >>>>>>>> world. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Fabien >>>>>>>> >>>>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >>>>>>>> >>>>>>>> Hello Francis, >>>>>>>> >>>>>>>> See two comments in line. >>>>>>>> >>>>>>>> >>>>>>>> B) Current Document >>>>>>>> >>>>>>>> Roles description shall not hold any assumption on the physical >>>>>>>> structure of the party fulfilling the roles. >>>>>>>> [FI] not sure what you mean >>>>>>>> >>>>>>>> [FP] for example, we assume the AS is a server! In most SSI based >>>>>>>> use cases, the AS will be running on the user device. See SIOP ( >>>>>>>> https://identity.foundation/did-siop/). >>>>>>>> >>>>>>>> I browsed through the two drafts, i.e. : >>>>>>>> >>>>>>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >>>>>>>> model, and representations W3C Working Draft 08 November 2020 >>>>>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF >>>>>>>> Working Group Draft >>>>>>>> >>>>>>>> At no place within these two documents, it is possible to imagine >>>>>>>> that "the AS will be running on the user device". >>>>>>>> >>>>>>>> From section 3 of the DIF Working Group Draft: >>>>>>>> >>>>>>>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], >>>>>>>> the SIOP will not return an access token to the RP". >>>>>>>> >>>>>>>> An Identity Wallet is not an AS. >>>>>>>> >>>>>>>> >>>>>>>> Roles: >>>>>>>> -> grant endpoint of the AS: Why is this a post request? This >>>>>>>> eliminates the chance of having user device hosted AS (no server). >>>>>>>> [FI] what would you propose instead? >>>>>>>> Would also be interested to understand better the deployment model >>>>>>>> when there is no server. That's something that was discussed sever= al times >>>>>>>> but I'm still missing the underlying architecture and use case. >>>>>>>> >>>>>>>> [FP] See above (SIOP). There will be a lot of identity wallets >>>>>>>> operated on end user device. >>>>>>>> >>>>>>>> See the above comment. Please, do not confuse an Identity Wallet >>>>>>>> with an Authentication Server (AS). >>>>>>>> >>>>>>>> Denis >>>>>>>> >>>>>>>> >>>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it authorize >>>>>>>> the request or the access to a resource? >>>>>>>> [FI] yes, we should make the wording clearer >>>>>>>> >>>>>>>> Missing Section Interactions: >>>>>>>> --> This section shall introduce the notion of interaction before >>>>>>>> we start listing interaction types. >>>>>>>> [FI] yes >>>>>>>> >>>>>>>> Interaction Types: >>>>>>>> --> I prefer a classification with Redirect, Decoupled and Embedde= d >>>>>>>> is. In the draft, we have one redirect and 2 decouple interactions= and >>>>>>>> nothing else. >>>>>>>> [FI] this should be handled as a specific discussion item. As a >>>>>>>> reminder, how would you define embedded? >>>>>>>> >>>>>>>> In practice there's at least these modes: >>>>>>>> - redirect and redirect back >>>>>>>> - redirect to different browser or device >>>>>>>> - user code >>>>>>>> - CIBA >>>>>>>> >>>>>>>> [FP] This classification is limited. >>>>>>>> >>>>>>>> - Redirect: same device, same or different user agents >>>>>>>> (browser, mobile app, desktop app, ...) >>>>>>>> - Decoupled: different devices >>>>>>>> - Embedded : RC carries RO authorization to AS >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Resource Access Request vs. Resource Request >>>>>>>> --> Both are mixed up. No clarification of the context of each >>>>>>>> section. >>>>>>>> [FI] could you clarify what you'd expect. Btw on this topic, >>>>>>>> there's a more general discussion on whether we should make a dist= inction >>>>>>>> or not. >>>>>>>> >>>>>>>> =E2=80=8B[FP]: Here: >>>>>>>> >>>>>>>> - Resource Access Request: Requesting Access to a resource. >>>>>>>> Response is an access token (or any type of grant) >>>>>>>> - Resource Request: Request the resource. Response is the >>>>>>>> resource (or a corresponding execution) >>>>>>>> >>>>>>>> >>>>>>>> Token Content Negotiation >>>>>>>> --> Not expressed as such. This is central to GNAP and not >>>>>>>> represented enough in the document. >>>>>>>> [FI] right. This should be a specific discussion item. >>>>>>>> >>>>>>>> Requesting "User" Information >>>>>>>> we identify two types of users: RQ and RO. It will be better not t= o >>>>>>>> refer to a user in this draft, but either to a RQ or an RO. >>>>>>>> [FI] yes that would avoid potential misunderstandings. Although in >>>>>>>> the end, people will translate RQ into user or end-user most of th= e time. >>>>>>>> Cf in definition, currently we have Requesting Party (RQ, aka >>>>>>>> "user") >>>>>>>> >>>>>>>> >>>>>>>> Interaction Again >>>>>>>> -> For each interaction type, we will have to describe the protoco= l >>>>>>>> flow and the nature and behavior of involved Roles (Parties), Elem= ents, >>>>>>>> Requests. >>>>>>>> [FI] yes >>>>>>>> >>>>>>>> >>>>>>>> [FP] Will these and into tickets? >>>>>>>> >>>>>>>> Best regards. >>>>>>>> /Francis >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>>> >>>> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> > --000000000000a0e93205ba8795ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
doesn't work very well on windows uwp. works fine on s= martphones
Be the change you wan= t to see in the world ..tom

<= br>
On Thu,= Feb 4, 2021 at 11:18 AM Justin Richer <jricher@mit.edu> wrote:
OK, thanks =E2= =80=94 in that case, there are no changes at all to GNAP, which is already = HTTP driven. The harder parts tend to be where you can=E2=80=99t (or don=E2= =80=99t want to) use something like that.

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

On Feb 4, 2021, at 2:= 16 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

yes, loopback

Be the = change you want to see in the world ..tom

On Thu, Feb 4, 2021 at 11:01 AM Justin Richer <jricher@mit.edu> wrote:
=
Tom, can you expand = on how exactly the back-channel =C2=A0communication works between on-device= components? Do you use HTTP locally?

Thanks,
= =C2=A0=E2=80=94 Justin

On Feb 4,= 2021, at 1:03 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:
Justin's analysis of use of the front channel i= s misleading.
It could equally be argued that what i have done is insta= lled an AS on the phone and the communications with it & the PR is back= channel.
Basically the point is that the old OIDC paradigms are = no longer valid.
Be the change you want to see= in the world ..tom


On Thu, Feb 4, = 2021 at 7:47 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Yes, issue (= #168)=C2=A0message based interaction / DIDComm is a tentative alternative m= ecanism for the interaction part. Not sure how that would work in details= =C2=A0though, prototyping will probably help here.
Token delivery=C2=A0= through continuation seems fine to me. The client will probably have to wai= t for the next polling before it receives a token issued as the result of a= n asynchronous interaction, but that's not a big issue.

<= /div>
But the AS on the phone seems like a harder nut to crack, at leas= t at first sight. I think that would be awesome, but it gives me headaches,= so I think I'll work on easier stuff right now ;-)

Fabien=C2=A0=C2=A0

On Thu, Feb 4, 2021 at 4:30 PM Justin Ric= her <jricher@mit.ed= u> wrote:
One of the biggest drawbacks of the current app-centric approaches in= OIDC (self-issued OP, or SIOP) is that they depend on using the front chan= nel and browser redirects to pass everything, which is something that GNAP = is deliberately getting away from by starting in the back channel.

=
That said, once a request is kicked off in GNAP, the interaction= and fulfillment can happen through any number of means. Part of the work t= hat=E2=80=99s being done with the =E2=80=9Cinteraction=E2=80=9D section is = going to help facilitate this, and I think that there are some other potent= ial branches here.

Token delivery is where things = get extra weird though =E2=80=94 we are explicitly not delivering tokens in= the front channel in the core of GNAP, we=E2=80=99re using the response fr= om the continuation API. One idea (that isn=E2=80=99t particularly well tho= ught out and hasn=E2=80=99t been implemented at all) is to have an extensio= n declare an alternative response from the =E2=80=9Ccontinue=E2=80=9D secti= on that=E2=80=99s defined today, which points to the GNPA continuation API.= If an extension defines some alternative way to deliver tokens, that could= live alongside a continuation API and the client could indicate support fo= r it in its initial request.

In any event, alterna= tive interaction and delivery methods are important, and even if we aren=E2= =80=99t going to support every last one of them directly, the protocol desi= gn should at least be aware of them.

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

On Feb 4, 2021, at 8:= 35 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Tom,=C2=A0

Sure, any experience on that woul= d be greatly appreciated, we're calling for help here (the point being = that I suspect what they're doing is not trivial).

=
Fabien

On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gma= il.com> wrote:
I've had such an app working for over a year. T= here are issues which are being addressed by the browser Interaction team o= f oidc.

thx ..Tom (mobile)

On Thu, Feb 4, 2021, 3:12 AM Fa= bien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,=C2=A0

I've tried a few things with regards to using the AS on a phone,= but it's really quite=C2=A0complex.=C2=A0

Mak= ing that run on a phone comes with quite a bit of trouble. The most difficu= lt part if that we'd need to use a secure element, but just installing = and hosting a http server securely is not a standard setup at all. I sugges= t interested people step in to work on this, as we already have a lot of wo= rk for the (more usual) server case and already handle a privacy preserving= scheme.=C2=A0

Please let us know what you think.<= /div>

Cheers,
Fabien=C2=A0

On Tue, Nov 24= , 2020 at 5:55 AM Fabien Imbault <fabien.imbault@gmail.com>= wrote:
Hi Francis,

I&#= 39;ve thought a bit more to what you said. I think I'll give it a try a= s a separate experiment (in code, not in theory). Not that I would expect i= t to be included in GNAP, but I kind of like the idea :-)

The direct impact for GNAP would be to th= ink about multiple ASs.=C2=A0

Will let you know.=C2=A0

Fabien=C2=A0


Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha = <= fpo@adorsys.de> a =C3=A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"gmail-m_-542839070341023388gmail-m_-6176056956474019294gmail-m_-3037161= 202240578685gmail-m_-7520389457378808664gmail-m_-3342024782330569254m_80147= 00032835912204gmail-m_142651873244800559m_8348797445460806175LPlnk338391" r= el=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/ietf-wg-g= nap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <fabien.imbault@gmail.= com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>;= Dick Hardt <dick.hardt@gmail.com>; Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <= txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com<= /a>>
Cc: Fabien Imbault <fabien.imbault@gmail.com= >; Denis <denis.ietf@free.fr>; GNAP Mailing List &l= t;txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://yo= utu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabi= en.imbault@gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentralized= -02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis= .ietf@free.fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundati= on/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= =E2=80=8B= [FP]: Here:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth=


--000000000000a0e93205ba8795ca-- From nobody Thu Feb 4 11:43:52 2021 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 2130D3A1783 for ; Thu, 4 Feb 2021 11:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 tFPw19uYFQkc for ; Thu, 4 Feb 2021 11:43:47 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 E05263A1785 for ; Thu, 4 Feb 2021 11:43:46 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id n2so4506022iom.7 for ; Thu, 04 Feb 2021 11:43:46 -0800 (PST) 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=KjDiqY8FY+ze7fvq28Yh3YpAFZEoLvr7XKQy8cVpt1w=; b=hpL7baf1UIbCX6bWmAhzoI1YQwH1IBk6S4y0Ri9HCk7LEJyRi541p5LKdfuHFLxB/W wDYw3CF73AF581UtpQq+uA7+h/IOoOc3EKO0uBAuEj7BJKVzyf4oEIeERMuzm54wzF6N +DJY/JrKUXE9xDL6m2P5/f/wFpohn0NRacoAnwjP2Yazl3u5y2//DMlBiyyBAzhM9QF0 XbKebvqsBF+Ht7glaAIxupGdQXPEznTnkhptonm5+F8OLI7n+OCCxjCI6DP1qsZ/3RgY uEyXnUc+TJXJy7XQusv3D6TScvGqBFOD2z90kK9x2nsoQhNbTdkZe6HoE8Nz2XT1/QOD IrwQ== 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=KjDiqY8FY+ze7fvq28Yh3YpAFZEoLvr7XKQy8cVpt1w=; b=HHSXKbwOIwDY0kiBUORSiGNdnk8WMONucdOfp8jlS5lSVLn1FBS6YRK9OynqS6p2py IK3oSjEQ/q438yQSRPm22PNMvieE4D/p0Z2DGl8zdJu4cFC8TZxr+3MSRYAS2SZpd6x6 7tPu5X6RGKF1+jeoxcuzz5TVF9/j2hgL9FexKfDntt5jMHuhiTq3xPgCXgpp81ub7RCk wY4rou71q3Jj9musHFGIFgVE59KWHTi9XbgSmAQduDXW3OAf83rxPzHSDDYBNwdiNFBJ cqmQINRDLkavPkJeQaVeGKFzLWSDCw10knhQHWFYDKSKZxhLVp/NWNMVXc4XzQQojYVF 2XpA== X-Gm-Message-State: AOAM533uYk6sKz1FtXiQlIbndhiTlHc0khs2DgauRErWP/pT5FUChYnX YyvrWpBfVGlqRd360S6AvhlTtz16citzKgg5JE4= X-Google-Smtp-Source: ABdhPJw98/YGJGTMWpVA/Cq6PKrYGh8WSn6xGBLa/vTODwa/fEw1bpTbzWk8/l5/QrCNyszIF/huLOwjbtvI/zAvXDY= X-Received: by 2002:a6b:680e:: with SMTP id d14mr870331ioc.74.1612467825992; Thu, 04 Feb 2021 11:43:45 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> <77D1AE7B-076F-4095-8FAA-7C35D74614BD@mit.edu> In-Reply-To: From: Fabien Imbault Date: Thu, 4 Feb 2021 20:43:32 +0100 Message-ID: To: Tom Jones Cc: Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="000000000000fae91205ba87ebc3" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 19:43:51 -0000 --000000000000fae91205ba87ebc3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Fair enough. But loopback limits a lot what you can do... Just for debug it's a pain. But as soon as you try more, it's a bit crazy. Fun to test ipv6 (luckily supported by my ISP) and ddns. But it feels really hacky. Also deployment is a pain, compared to a traditional webserver. Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones a =C3=A9crit : > doesn't work very well on windows uwp. works fine on smartphones > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 11:18 AM Justin Richer wrote: > >> OK, thanks =E2=80=94 in that case, there are no changes at all to GNAP, = which is >> already HTTP driven. The harder parts tend to be where you can=E2=80=99t= (or don=E2=80=99t >> want to) use something like that. >> >> =E2=80=94 Justin >> >> On Feb 4, 2021, at 2:16 PM, Tom Jones >> wrote: >> >> yes, loopback >> >> Be the change you want to see in the world ..tom >> >> >> On Thu, Feb 4, 2021 at 11:01 AM Justin Richer wrote: >> >>> Tom, can you expand on how exactly the back-channel communication work= s >>> between on-device components? Do you use HTTP locally? >>> >>> Thanks, >>> =E2=80=94 Justin >>> >>> On Feb 4, 2021, at 1:03 PM, Tom Jones >>> wrote: >>> >>> Justin's analysis of use of the front channel is misleading. >>> It could equally be argued that what i have done is installed an AS on >>> the phone and the communications with it & the PR is back channel. >>> Basically the point is that the old OIDC paradigms are no longer valid. >>> Be the change you want to see in the world ..tom >>> >>> >>> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault >>> wrote: >>> >>>> Yes, issue (#168) message based interaction / DIDComm is a tentative >>>> alternative mecanism for the interaction part. Not sure how that would= work >>>> in details though, prototyping will probably help here. >>>> Token delivery through continuation seems fine to me. The client will >>>> probably have to wait for the next polling before it receives a token >>>> issued as the result of an asynchronous interaction, but that's not a = big >>>> issue. >>>> >>>> But the AS on the phone seems like a harder nut to crack, at least at >>>> first sight. I think that would be awesome, but it gives me headaches,= so I >>>> think I'll work on easier stuff right now ;-) >>>> >>>> Fabien >>>> >>>> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer wrote: >>>> >>>>> One of the biggest drawbacks of the current app-centric approaches in >>>>> OIDC (self-issued OP, or SIOP) is that they depend on using the front >>>>> channel and browser redirects to pass everything, which is something = that >>>>> GNAP is deliberately getting away from by starting in the back channe= l. >>>>> >>>>> That said, once a request is kicked off in GNAP, the interaction and >>>>> fulfillment can happen through any number of means. Part of the work = that=E2=80=99s >>>>> being done with the =E2=80=9Cinteraction=E2=80=9D section is going to= help facilitate this, >>>>> and I think that there are some other potential branches here. >>>>> >>>>> Token delivery is where things get extra weird though =E2=80=94 we ar= e >>>>> explicitly not delivering tokens in the front channel in the core of = GNAP, >>>>> we=E2=80=99re using the response from the continuation API. One idea = (that isn=E2=80=99t >>>>> particularly well thought out and hasn=E2=80=99t been implemented at = all) is to >>>>> have an extension declare an alternative response from the =E2=80=9Cc= ontinue=E2=80=9D >>>>> section that=E2=80=99s defined today, which points to the GNPA contin= uation API. If >>>>> an extension defines some alternative way to deliver tokens, that cou= ld >>>>> live alongside a continuation API and the client could indicate suppo= rt for >>>>> it in its initial request. >>>>> >>>>> In any event, alternative interaction and delivery methods are >>>>> important, and even if we aren=E2=80=99t going to support every last = one of them >>>>> directly, the protocol design should at least be aware of them. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault >>>>> wrote: >>>>> >>>>> Hi Tom, >>>>> >>>>> Sure, any experience on that would be greatly appreciated, we're >>>>> calling for help here (the point being that I suspect what they're do= ing is >>>>> not trivial). >>>>> >>>>> Fabien >>>>> >>>>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones >>>>> wrote: >>>>> >>>>>> I've had such an app working for over a year. There are issues which >>>>>> are being addressed by the browser Interaction team of oidc. >>>>>> >>>>>> thx ..Tom (mobile) >>>>>> >>>>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault >>>>>> wrote: >>>>>> >>>>>>> Hi Francis, >>>>>>> >>>>>>> I've tried a few things with regards to using the AS on a phone, bu= t >>>>>>> it's really quite complex. >>>>>>> >>>>>>> Making that run on a phone comes with quite a bit of trouble. The >>>>>>> most difficult part if that we'd need to use a secure element, but = just >>>>>>> installing and hosting a http server securely is not a standard set= up at >>>>>>> all. I suggest interested people step in to work on this, as we alr= eady >>>>>>> have a lot of work for the (more usual) server case and already han= dle a >>>>>>> privacy preserving scheme. >>>>>>> >>>>>>> Please let us know what you think. >>>>>>> >>>>>>> Cheers, >>>>>>> Fabien >>>>>>> >>>>>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Hi Francis, >>>>>>>> >>>>>>>> I've thought a bit more to what you said. I think I'll give it a >>>>>>>> try as a separate experiment (in code, not in theory). Not that I = would >>>>>>>> expect it to be included in GNAP, but I kind of like the idea :-) >>>>>>>> >>>>>>>> The direct impact for GNAP would be to think about multiple ASs. >>>>>>>> >>>>>>>> Will let you know. >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> >>>>>>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha a >>>>>>>> =C3=A9crit : >>>>>>>> >>>>>>>>> It would be nice if the protocol was designed at many layers of >>>>>>>>> abstraction. >>>>>>>>> >>>>>>>>> >>>>>>>>> - The first layer shall design abstract protocol flows, >>>>>>>>> without specification of the mode and mechanism of interaction= . >>>>>>>>> - The second layer can instantiate the first layer for >>>>>>>>> dedicated interaction. Here we can talk http, we can define in= teractions >>>>>>>>> that presume server based token generation, we can define inte= raction that >>>>>>>>> run on user device based token generation. >>>>>>>>> >>>>>>>>> This is also the fundament of the structure I proposed for the >>>>>>>>> spec (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/3= 0 >>>>>>>>> ). >>>>>>>>> >>>>>>>>> /Francis >>>>>>>>> >>>>>>>>> ------------------------------ >>>>>>>>> *From:* Fabien Imbault >>>>>>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>>>>>>> *To:* Francis Pouatcha >>>>>>>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>>>>>>> dick.hardt@gmail.com>; Tom Jones ; >>>>>>>>> Denis ; Justin Richer >>>>>>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>>>>>> >>>>>>>>> Would make sense, but not so easy as we rely heavily on HTTP. >>>>>>>>> Hence the discussion about deep links and so on. >>>>>>>>> >>>>>>>>> An alternative might be provided by wasm/wasi (running a local >>>>>>>>> sandbox on your phone, for your own AS), but it's really early st= age. This >>>>>>>>> also poses another question that Denis has put forward, i.e. how = do we >>>>>>>>> handle the multiple AS scenario (likely to occur then). >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> We are drifting away from the original problem space. >>>>>>>>> >>>>>>>>> - My original mention was about the "POST" request, that >>>>>>>>> subsumes that the "AS" is a "Server". Designing a new protocol= , we cannot >>>>>>>>> afford this limitation. >>>>>>>>> - I just mentioned SIOP to show a known and closed example? >>>>>>>>> Let us not focus on the device local discovery scheme (like op= enid:) for >>>>>>>>> now. >>>>>>>>> - As capability of holding private keys on user device >>>>>>>>> evolves, server-based issuing of token will be fading out givi= ng way to >>>>>>>>> device local generation of token. >>>>>>>>> >>>>>>>>> While designing GNAP, let us assume the AS-Role can be exercised >>>>>>>>> on a user device and design the protocol to honor that. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> /Francis >>>>>>>>> ------------------------------ >>>>>>>>> *From:* TXAuth on behalf of Dick Hardt = < >>>>>>>>> dick.hardt@gmail.com> >>>>>>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>>>>>>> *To:* Tom Jones >>>>>>>>> *Cc:* Fabien Imbault ; Denis < >>>>>>>>> denis.ietf@free.fr>; GNAP Mailing List ; Justin >>>>>>>>> Richer >>>>>>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>>>>>> >>>>>>>>> Got it. >>>>>>>>> >>>>>>>>> So web apps invoke a openid: deep link and hope there is an app t= o >>>>>>>>> handle the openid: scheme? ... and that it is the user's wallet r= ather than >>>>>>>>> some malware that has registered openid: on the mobile device? >>>>>>>>> >>>>>>>>> A native app can attempt to open a deep link associated with an >>>>>>>>> app, and will fail if the app is not there. If the app is there, = it will be >>>>>>>>> opened, so this can't be used to silently test if an app is prese= nt, but it >>>>>>>>> does allow a native app to provide an alternative experience if a= n app is >>>>>>>>> not present. I don't think this works with custom schemes ... and= I don't >>>>>>>>> know how it could work from a web app on the phone with the curre= nt Safari >>>>>>>>> APIs. >>>>>>>>> >>>>>>>>> Apple warns against using custom schemes [1] ... but perhaps they >>>>>>>>> can be convinced to make openid: a managed scheme similar to mail= to:, >>>>>>>>> tel:, sms:, facetime: ? >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> https://developer.apple.com/documentation/xcode/allowing_apps_and= _websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app >>>>>>>>> >>>>>>>>> >>>>>>>>> =E1=90=A7 >>>>>>>>> >>>>>>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>> >>>>>>>>> You are - that is not standard which is opeind:// >>>>>>>>> This is the one step that still needs to be optimized for SIOP to >>>>>>>>> have good UX. >>>>>>>>> Peace ..tom >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Tom >>>>>>>>> >>>>>>>>> I watched your video (I watched at 2X speed) >>>>>>>>> >>>>>>>>> Looks like the employment website app that is using localhost:876= 5 >>>>>>>>> to communicate with the wallet. Am I correct? >>>>>>>>> >>>>>>>>> /Dick >>>>>>>>> =E1=90=A7 >>>>>>>>> >>>>>>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones < >>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>> >>>>>>>>> Well, here's a demo. Note that in this case the AS is not online >>>>>>>>> all of the time, so it is really implicit flow and the OIDC id-to= ken comes >>>>>>>>> from the siop device directly. >>>>>>>>> (whether this is front-channel or back channel is no longer an >>>>>>>>> interesting question.) >>>>>>>>> Now if an always-on AS is required, that is possible, but probabl= y >>>>>>>>> beyond the scope of this effort and would require something like = an >>>>>>>>> agent-in-the-sky (with diamonds). >>>>>>>>> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW= 0 >>>>>>>>> >>>>>>>>> Peace ..tom >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Ultimately, in most situations like these in the real world, the >>>>>>>>> hurdle isn=E2=80=99t technical compatibility so much as it is tru= st compatibility. >>>>>>>>> The RP (client) needs to have some incentive to trust the asserti= ons and >>>>>>>>> identity information that=E2=80=99s coming from the AS. The same = is true for an RS >>>>>>>>> trusting tokens from the AS. The hard question is less =E2=80=9Ch= ow=E2=80=9D to do that >>>>>>>>> (which SSI answers), but more =E2=80=9Cwhy=E2=80=9D to do that (w= hich SSI doesn=E2=80=99t answer >>>>>>>>> very well, because it=E2=80=99s a hard question). >>>>>>>>> >>>>>>>>> Still: it=E2=80=99s definitely a question about how to support th= is =E2=80=9CAS on >>>>>>>>> device=E2=80=9D element. We=E2=80=99ve got the start of it more t= han OAuth2/OIDC have by >>>>>>>>> allowing the bootstrap of the process from a starting call: the i= nteraction >>>>>>>>> and continuation URIs handed back by the AS don=E2=80=99t need to= be the same URIs >>>>>>>>> that the client starts with, so just like SIOP the process can st= art in >>>>>>>>> HTTP and potentially move to other communication channels. A majo= r >>>>>>>>> difference is that we aren=E2=80=99t dependent on the assumption = that the user will >>>>>>>>> always be in a browser at some stage, and so the whole raft of >>>>>>>>> front-channel messages that SIOP relies on doesn=E2=80=99t fly. T= hat said, we=E2=80=99ve >>>>>>>>> got an opportunity to more explicitly open up alternative communi= cation >>>>>>>>> channels here, and that=E2=80=99s something I=E2=80=99d like to s= ee engineered, even if >>>>>>>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete pro= posal as to how that would >>>>>>>>> work over specific protocols, starting with what we=E2=80=99ve go= t today. >>>>>>>>> >>>>>>>>> =E2=80=94 Justin >>>>>>>>> >>>>>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>> Hi Denis, hi Francis, >>>>>>>>> >>>>>>>>> At some point integration with SSI (on the authentication side) >>>>>>>>> will probably occur, including amongst other possibilities SIOP (= since they >>>>>>>>> work with OpenID a part of the work will probably be made easier)= . >>>>>>>>> >>>>>>>>> That being said, Denis is right. It's not an AS. Technically it's >>>>>>>>> entirely possible to rely on a decentralized wallet (for instance= on your >>>>>>>>> phone) and a centralized AS. I know of a few studies on how to de= centralize >>>>>>>>> the AS itself (for instance >>>>>>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02 >>>>>>>>> ). >>>>>>>>> Maybe it exists, but I'm still looking for real scenarios (or eve= n >>>>>>>>> architectures) where an AS is deployed directly on a phone, and u= nder the >>>>>>>>> sole authority of the RO, while being compatible with the rest of= the >>>>>>>>> world. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >>>>>>>>> >>>>>>>>> Hello Francis, >>>>>>>>> >>>>>>>>> See two comments in line. >>>>>>>>> >>>>>>>>> >>>>>>>>> B) Current Document >>>>>>>>> >>>>>>>>> Roles description shall not hold any assumption on the physical >>>>>>>>> structure of the party fulfilling the roles. >>>>>>>>> [FI] not sure what you mean >>>>>>>>> >>>>>>>>> [FP] for example, we assume the AS is a server! In most SSI base= d >>>>>>>>> use cases, the AS will be running on the user device. See SIOP ( >>>>>>>>> https://identity.foundation/did-siop/). >>>>>>>>> >>>>>>>>> I browsed through the two drafts, i.e. : >>>>>>>>> >>>>>>>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, >>>>>>>>> data model, and representations W3C Working Draft 08 November = 2020 >>>>>>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF >>>>>>>>> Working Group Draft >>>>>>>>> >>>>>>>>> At no place within these two documents, it is possible to imagine >>>>>>>>> that "the AS will be running on the user device". >>>>>>>>> >>>>>>>>> From section 3 of the DIF Working Group Draft: >>>>>>>>> >>>>>>>>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core]= , >>>>>>>>> the SIOP will not return an access token to the RP". >>>>>>>>> >>>>>>>>> An Identity Wallet is not an AS. >>>>>>>>> >>>>>>>>> >>>>>>>>> Roles: >>>>>>>>> -> grant endpoint of the AS: Why is this a post request? This >>>>>>>>> eliminates the chance of having user device hosted AS (no server)= . >>>>>>>>> [FI] what would you propose instead? >>>>>>>>> Would also be interested to understand better the deployment mode= l >>>>>>>>> when there is no server. That's something that was discussed seve= ral times >>>>>>>>> but I'm still missing the underlying architecture and use case. >>>>>>>>> >>>>>>>>> [FP] See above (SIOP). There will be a lot of identity wallets >>>>>>>>> operated on end user device. >>>>>>>>> >>>>>>>>> See the above comment. Please, do not confuse an Identity Wallet >>>>>>>>> with an Authentication Server (AS). >>>>>>>>> >>>>>>>>> Denis >>>>>>>>> >>>>>>>>> >>>>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it authoriz= e >>>>>>>>> the request or the access to a resource? >>>>>>>>> [FI] yes, we should make the wording clearer >>>>>>>>> >>>>>>>>> Missing Section Interactions: >>>>>>>>> --> This section shall introduce the notion of interaction before >>>>>>>>> we start listing interaction types. >>>>>>>>> [FI] yes >>>>>>>>> >>>>>>>>> Interaction Types: >>>>>>>>> --> I prefer a classification with Redirect, Decoupled and >>>>>>>>> Embedded is. In the draft, we have one redirect and 2 decouple in= teractions >>>>>>>>> and nothing else. >>>>>>>>> [FI] this should be handled as a specific discussion item. As a >>>>>>>>> reminder, how would you define embedded? >>>>>>>>> >>>>>>>>> In practice there's at least these modes: >>>>>>>>> - redirect and redirect back >>>>>>>>> - redirect to different browser or device >>>>>>>>> - user code >>>>>>>>> - CIBA >>>>>>>>> >>>>>>>>> [FP] This classification is limited. >>>>>>>>> >>>>>>>>> - Redirect: same device, same or different user agents >>>>>>>>> (browser, mobile app, desktop app, ...) >>>>>>>>> - Decoupled: different devices >>>>>>>>> - Embedded : RC carries RO authorization to AS >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Resource Access Request vs. Resource Request >>>>>>>>> --> Both are mixed up. No clarification of the context of each >>>>>>>>> section. >>>>>>>>> [FI] could you clarify what you'd expect. Btw on this topic, >>>>>>>>> there's a more general discussion on whether we should make a dis= tinction >>>>>>>>> or not. >>>>>>>>> >>>>>>>>> =E2=80=8B[FP]: Here: >>>>>>>>> >>>>>>>>> - Resource Access Request: Requesting Access to a resource. >>>>>>>>> Response is an access token (or any type of grant) >>>>>>>>> - Resource Request: Request the resource. Response is the >>>>>>>>> resource (or a corresponding execution) >>>>>>>>> >>>>>>>>> >>>>>>>>> Token Content Negotiation >>>>>>>>> --> Not expressed as such. This is central to GNAP and not >>>>>>>>> represented enough in the document. >>>>>>>>> [FI] right. This should be a specific discussion item. >>>>>>>>> >>>>>>>>> Requesting "User" Information >>>>>>>>> we identify two types of users: RQ and RO. It will be better not >>>>>>>>> to refer to a user in this draft, but either to a RQ or an RO. >>>>>>>>> [FI] yes that would avoid potential misunderstandings. Although i= n >>>>>>>>> the end, people will translate RQ into user or end-user most of t= he time. >>>>>>>>> Cf in definition, currently we have Requesting Party (RQ, aka >>>>>>>>> "user") >>>>>>>>> >>>>>>>>> >>>>>>>>> Interaction Again >>>>>>>>> -> For each interaction type, we will have to describe the >>>>>>>>> protocol flow and the nature and behavior of involved Roles (Part= ies), >>>>>>>>> Elements, Requests. >>>>>>>>> [FI] yes >>>>>>>>> >>>>>>>>> >>>>>>>>> [FP] Will these and into tickets? >>>>>>>>> >>>>>>>>> Best regards. >>>>>>>>> /Francis >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> TXAuth mailing list >>>>>>>>> TXAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>> >>>>>>>>> -- >>>>>>>>> TXAuth mailing list >>>>>>>>> TXAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> TXAuth mailing list >>>>>>>>> TXAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>> >>>>>>>>> -- >>>>>>>>> TXAuth mailing list >>>>>>>>> TXAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>> >>>>>>>>> >>>>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000fae91205ba87ebc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Fair enough. But loopback limits a lot what you can do...= Just for debug it's a pain.=C2=A0
But as soon as you = try more, it's a bit crazy. Fun to test ipv6 (luckily supported by my I= SP) and ddns. But it feels really hacky.=C2=A0
Also = deployment is a pain, compared to a traditional webserver.=C2=A0

Le je= u. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit=C2=A0:
doesn't work ve= ry well on windows uwp. works fine on smartphones
Be the ch= ange you want to see in the world ..tom

<= /div>

On Thu, Feb 4, 2021 at 11:18 AM Justin Richer <jricher@mit.edu> wrote:
OK, thanks =E2=80=94 in that case,= there are no changes at all to GNAP, which is already HTTP driven. The har= der parts tend to be where you can=E2=80=99t (or don=E2=80=99t want to) use= something like that.

=C2=A0=E2=80=94 Justin
On Feb 4, 2021, at 2:16 PM, Tom Jones <<= a href=3D"mailto:thomasclinganjones@gmail.com" rel=3D"noreferrer noreferrer= noreferrer noreferrer noreferrer" target=3D"_blank">thomasclinganjones@gma= il.com> wrote:

yes, loopback

Be the change you want to see in the worl= d ..tom


On Thu, Feb 4, 2021 at 11:0= 1 AM Justin Richer <jricher@mit= .edu> wrote:
Tom, can you expand on how exactly the back-channel =C2=A0communic= ation works between on-device components? Do you use HTTP locally?

=
Thanks,
=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 1:03 PM, Tom Jones <thomasclinganjones@gmail.com&g= t; wrote:

Justin's analysis of use of th= e front channel is misleading.
It could equally be argued that what i h= ave done is installed an AS on the phone and the communications with it &am= p; the PR is back channel.
Basically the point is that the old OI= DC paradigms are no longer valid.
Be the chang= e you want to see in the world ..tom


On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Yes, is= sue (#168)=C2=A0message based interaction / DIDComm is a tentative alternat= ive mecanism for the interaction part. Not sure how that would work in deta= ils=C2=A0though, prototyping will probably help here.
Token delivery=C2= =A0through continuation seems fine to me. The client will probably have to = wait for the next polling before it receives a token issued as the result o= f an asynchronous interaction, but that's not a big issue.
But the AS on the phone seems like a harder nut to crack, at l= east at first sight. I think that would be awesome, but it gives me headach= es, so I think I'll work on easier stuff right now ;-)

Fabien=C2=A0=C2=A0

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 4, 2021 at 4:30 PM Justin = Richer <jricher@mit.edu>= wrote:
One= of the biggest drawbacks of the current app-centric approaches in OIDC (se= lf-issued OP, or SIOP) is that they depend on using the front channel and b= rowser redirects to pass everything, which is something that GNAP is delibe= rately getting away from by starting in the back channel.

That said, once a request is kicked off in GNAP, the interaction and fulf= illment can happen through any number of means. Part of the work that=E2=80= =99s being done with the =E2=80=9Cinteraction=E2=80=9D section is going to = help facilitate this, and I think that there are some other potential branc= hes here.

Token delivery is where things get extra= weird though =E2=80=94 we are explicitly not delivering tokens in the fron= t channel in the core of GNAP, we=E2=80=99re using the response from the co= ntinuation API. One idea (that isn=E2=80=99t particularly well thought out = and hasn=E2=80=99t been implemented at all) is to have an extension declare= an alternative response from the =E2=80=9Ccontinue=E2=80=9D section that= =E2=80=99s defined today, which points to the GNPA continuation API. If an = extension defines some alternative way to deliver tokens, that could live a= longside a continuation API and the client could indicate support for it in= its initial request.

In any event, alternative in= teraction and delivery methods are important, and even if we aren=E2=80=99t= going to support every last one of them directly, the protocol design shou= ld at least be aware of them.

=C2=A0=E2=80=94 Just= in

On Feb 4, 2021, at 8:35 AM, F= abien Imbault <fabien.= imbault@gmail.com> wrote:

Hi Tom,=C2= =A0

Sure, any experience on that would be greatly apprec= iated, we're calling for help here (the point being that I suspect what= they're doing is not trivial).

Fabien

On= Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
=
I'v= e had such an app working for over a year. There are issues which are being= addressed by the browser Interaction team of oidc.

thx ..Tom (= mobile)

On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:=
Hi Francis,=C2=A0

I've tried a few things with reg= ards to using the AS on a phone, but it's really quite=C2=A0complex.=C2= =A0

Making that run on a phone comes with quite a = bit of trouble. The most difficult part if that we'd need to use a secu= re element, but just installing and hosting a http server securely is not a= standard setup at all. I suggest interested people step in to work on this= , as we already have a lot of work for the (more usual) server case and alr= eady handle a privacy preserving scheme.=C2=A0

Ple= ase let us know what you think.

Cheers,
= Fabien=C2=A0

On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault <fabien.imbault@gmail= .com> wrote:
Hi Francis,

I've thought a bit more to what you said. I think I'll gi= ve it a try as a separate experiment (in code, not in theory). Not that I w= ould expect it to be included in GNAP, but I kind of like the idea :-)

The direct impact for GNAP w= ould be to think about multiple ASs.=C2=A0

Will let you know.=C2=A0

Fabien=C2=A0


Le mer. 18 nov. 2020 =C3=A0 13:06, Fran= cis Pouatcha <fpo@ado= rsys.de> a =C3=A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"m_-3004232231493229381m_-8862550958674531306m_4552653984562635461m_3879= 29924441527190m_6662104191003806385gmail-m_-542839070341023388gmail-m_-6176= 056956474019294gmail-m_-3037161202240578685gmail-m_-7520389457378808664gmai= l-m_-3342024782330569254m_8014700032835912204gmail-m_142651873244800559m_83= 48797445460806175LPlnk338391" rel=3D"noreferrer noreferrer noreferrer noref= errer noreferrer noreferrer noreferrer" target=3D"_blank">https://github.co= m/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <fabien.imb= ault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: t= xauth@ietf.org <txauth@ietf.org>; Dick Hardt <dick.hardt@gmail.com>; = Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@adorsys.de> wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From:<= /b> TXAuth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@fr= ee.fr>; GNAP Mailing List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclin= ganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.c= om> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomascling= anjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.be<= /span>/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu= > wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com= > wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https:/= /tools.ietf.org/html/draft-hardjono-oauth-decentralized-02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr>= ; wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= =E2=80=8B= [FP]: Here:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


--
TXAuth mailing list
TXAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/txauth
--000000000000fae91205ba87ebc3-- From nobody Thu Feb 4 12:20:36 2021 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 C74373A17BE for ; Thu, 4 Feb 2021 12:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 fJtRGXgDQ0SB for ; Thu, 4 Feb 2021 12:20:31 -0800 (PST) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 BE4843A17BD for ; Thu, 4 Feb 2021 12:20:30 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id s107so4692423otb.8 for ; Thu, 04 Feb 2021 12:20:30 -0800 (PST) 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=aLtqmewo0OiPIMLqD9aOSlGSKto+ZkiXxpuOxLphsew=; b=Kcqsu0/8yv3YPJnnAMGYfYhf/b/u/FZ1lM24oa34jdKOwyDq0wHew5xKg5W+/muhjf Jbo2oRG5a3wy0oJoZAGEYLIxpkjCLue1UmL6nySidIujlrsz4rhMpU/fuHjytuqWzXue BDR50NWnqYx8drRkWEulL2NxReEwvG7Lb6EB4nbwMIAvGdDfxm1emelXkeBdQWzrIP9q lLNbTL066Y0nbo61I/xTAJotV/OaDYg2dU7bmWgTjpHDLwg/+QKk5lDnM5VUk1TV0ETd mUEU8OiQAjFimpckpvTkZiAOMK1i7D7M9he6aLbpOL/A6D+A5fdWpuS8fft1ndaANUM0 U2Ug== 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=aLtqmewo0OiPIMLqD9aOSlGSKto+ZkiXxpuOxLphsew=; b=RhUAdoqKGk0PiUsZ23BBYwbixma7BNexz31at78Bnvc+CKuqqM9MhutzjAPjEagH8R wqALjHJXpv1QbCU5Kqyd3RVcD0EEK7DYkv8nNhBKedpXTMppxpOnSxDuOzJAZ19EmfHT 6n0oVjLDB/bLgeA0OM7TmNyieu/A6BBXPAogExZNPj8qj5T9byLnLP+BPtUd7w26kZ4A ts7HU46Uwv8lRiccl7sXdTxphBaXL12PW/QsTMnE6v/utCj3LrKvb7HWzfGJQZ9IdQZ9 D6BgkeuvuxyzSfTzVJJ7Il1jvQtupQGb3A3YJwpEpajYv1dQzvMHHdXXXLvuS3TwWDg0 0chQ== X-Gm-Message-State: AOAM531zKAdcDIHopkY89UVy0TqTy4p4n4WkoWOteXF+bdRvaivrdRj9 DeHN8EJ7KzCY5yJrBUnSbipe3l5qCxV5xJjvmoU= X-Google-Smtp-Source: ABdhPJwB/lQhgkwr+C+/cbYfDY+W9WxHrgfV7kbVNqjPNXIPoSsEl2QhWSvH4gVSLQZqY6f9+qV+LwipYTbKArHrc/A= X-Received: by 2002:a9d:37c4:: with SMTP id x62mr864913otb.87.1612470029754; Thu, 04 Feb 2021 12:20:29 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> <77D1AE7B-076F-4095-8FAA-7C35D74614BD@mit.edu> In-Reply-To: From: Tom Jones Date: Thu, 4 Feb 2021 12:20:17 -0800 Message-ID: To: Fabien Imbault Cc: Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="00000000000055a50f05ba886f7a" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 20:20:35 -0000 --00000000000055a50f05ba886f7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable i assumed that the wallet (aka AS) needed to be a native app, not a PWA (which can come from a traditional web server). There are folks, lke Kim C, who are working on a PWA, but i agree the blocks there seem to be large. THe blocks on a native app are simple, easy to describe, and easy to ask the browser guys to fix. Not sure if they care tho. I have trouble seeing a path to GNAP adoption for retail customers w/o some browser support. That's why i am mostly silent here. Be the change you want to see in the world ..tom On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault wrote: > Fair enough. But loopback limits a lot what you can do... Just for debug > it's a pain. > But as soon as you try more, it's a bit crazy. Fun to test ipv6 (luckily > supported by my ISP) and ddns. But it feels really hacky. > Also deployment is a pain, compared to a traditional webserver. > > Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones a > =C3=A9crit : > >> doesn't work very well on windows uwp. works fine on smartphones >> Be the change you want to see in the world ..tom >> >> >> On Thu, Feb 4, 2021 at 11:18 AM Justin Richer wrote: >> >>> OK, thanks =E2=80=94 in that case, there are no changes at all to GNAP,= which is >>> already HTTP driven. The harder parts tend to be where you can=E2=80=99= t (or don=E2=80=99t >>> want to) use something like that. >>> >>> =E2=80=94 Justin >>> >>> On Feb 4, 2021, at 2:16 PM, Tom Jones >>> wrote: >>> >>> yes, loopback >>> >>> Be the change you want to see in the world ..tom >>> >>> >>> On Thu, Feb 4, 2021 at 11:01 AM Justin Richer wrote: >>> >>>> Tom, can you expand on how exactly the back-channel communication >>>> works between on-device components? Do you use HTTP locally? >>>> >>>> Thanks, >>>> =E2=80=94 Justin >>>> >>>> On Feb 4, 2021, at 1:03 PM, Tom Jones >>>> wrote: >>>> >>>> Justin's analysis of use of the front channel is misleading. >>>> It could equally be argued that what i have done is installed an AS on >>>> the phone and the communications with it & the PR is back channel. >>>> Basically the point is that the old OIDC paradigms are no longer valid= . >>>> Be the change you want to see in the world ..tom >>>> >>>> >>>> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault >>>> wrote: >>>> >>>>> Yes, issue (#168) message based interaction / DIDComm is a tentative >>>>> alternative mecanism for the interaction part. Not sure how that woul= d work >>>>> in details though, prototyping will probably help here. >>>>> Token delivery through continuation seems fine to me. The client will >>>>> probably have to wait for the next polling before it receives a token >>>>> issued as the result of an asynchronous interaction, but that's not a= big >>>>> issue. >>>>> >>>>> But the AS on the phone seems like a harder nut to crack, at least at >>>>> first sight. I think that would be awesome, but it gives me headaches= , so I >>>>> think I'll work on easier stuff right now ;-) >>>>> >>>>> Fabien >>>>> >>>>> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer wrote: >>>>> >>>>>> One of the biggest drawbacks of the current app-centric approaches i= n >>>>>> OIDC (self-issued OP, or SIOP) is that they depend on using the fron= t >>>>>> channel and browser redirects to pass everything, which is something= that >>>>>> GNAP is deliberately getting away from by starting in the back chann= el. >>>>>> >>>>>> That said, once a request is kicked off in GNAP, the interaction and >>>>>> fulfillment can happen through any number of means. Part of the work= that=E2=80=99s >>>>>> being done with the =E2=80=9Cinteraction=E2=80=9D section is going t= o help facilitate this, >>>>>> and I think that there are some other potential branches here. >>>>>> >>>>>> Token delivery is where things get extra weird though =E2=80=94 we a= re >>>>>> explicitly not delivering tokens in the front channel in the core of= GNAP, >>>>>> we=E2=80=99re using the response from the continuation API. One idea= (that isn=E2=80=99t >>>>>> particularly well thought out and hasn=E2=80=99t been implemented at= all) is to >>>>>> have an extension declare an alternative response from the =E2=80=9C= continue=E2=80=9D >>>>>> section that=E2=80=99s defined today, which points to the GNPA conti= nuation API. If >>>>>> an extension defines some alternative way to deliver tokens, that co= uld >>>>>> live alongside a continuation API and the client could indicate supp= ort for >>>>>> it in its initial request. >>>>>> >>>>>> In any event, alternative interaction and delivery methods are >>>>>> important, and even if we aren=E2=80=99t going to support every last= one of them >>>>>> directly, the protocol design should at least be aware of them. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault >>>>>> wrote: >>>>>> >>>>>> Hi Tom, >>>>>> >>>>>> Sure, any experience on that would be greatly appreciated, we're >>>>>> calling for help here (the point being that I suspect what they're d= oing is >>>>>> not trivial). >>>>>> >>>>>> Fabien >>>>>> >>>>>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones < >>>>>> thomasclinganjones@gmail.com> wrote: >>>>>> >>>>>>> I've had such an app working for over a year. There are issues whic= h >>>>>>> are being addressed by the browser Interaction team of oidc. >>>>>>> >>>>>>> thx ..Tom (mobile) >>>>>>> >>>>>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Hi Francis, >>>>>>>> >>>>>>>> I've tried a few things with regards to using the AS on a phone, >>>>>>>> but it's really quite complex. >>>>>>>> >>>>>>>> Making that run on a phone comes with quite a bit of trouble. The >>>>>>>> most difficult part if that we'd need to use a secure element, but= just >>>>>>>> installing and hosting a http server securely is not a standard se= tup at >>>>>>>> all. I suggest interested people step in to work on this, as we al= ready >>>>>>>> have a lot of work for the (more usual) server case and already ha= ndle a >>>>>>>> privacy preserving scheme. >>>>>>>> >>>>>>>> Please let us know what you think. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Fabien >>>>>>>> >>>>>>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi Francis, >>>>>>>>> >>>>>>>>> I've thought a bit more to what you said. I think I'll give it a >>>>>>>>> try as a separate experiment (in code, not in theory). Not that I= would >>>>>>>>> expect it to be included in GNAP, but I kind of like the idea :-) >>>>>>>>> >>>>>>>>> The direct impact for GNAP would be to think about multiple ASs. >>>>>>>>> >>>>>>>>> Will let you know. >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> >>>>>>>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha a >>>>>>>>> =C3=A9crit : >>>>>>>>> >>>>>>>>>> It would be nice if the protocol was designed at many layers of >>>>>>>>>> abstraction. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - The first layer shall design abstract protocol flows, >>>>>>>>>> without specification of the mode and mechanism of interactio= n. >>>>>>>>>> - The second layer can instantiate the first layer for >>>>>>>>>> dedicated interaction. Here we can talk http, we can define i= nteractions >>>>>>>>>> that presume server based token generation, we can define int= eraction that >>>>>>>>>> run on user device based token generation. >>>>>>>>>> >>>>>>>>>> This is also the fundament of the structure I proposed for the >>>>>>>>>> spec ( >>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). >>>>>>>>>> >>>>>>>>>> /Francis >>>>>>>>>> >>>>>>>>>> ------------------------------ >>>>>>>>>> *From:* Fabien Imbault >>>>>>>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>>>>>>>> *To:* Francis Pouatcha >>>>>>>>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>>>>>>>> dick.hardt@gmail.com>; Tom Jones ; >>>>>>>>>> Denis ; Justin Richer >>>>>>>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>>>>>>> >>>>>>>>>> Would make sense, but not so easy as we rely heavily on HTTP. >>>>>>>>>> Hence the discussion about deep links and so on. >>>>>>>>>> >>>>>>>>>> An alternative might be provided by wasm/wasi (running a local >>>>>>>>>> sandbox on your phone, for your own AS), but it's really early s= tage. This >>>>>>>>>> also poses another question that Denis has put forward, i.e. how= do we >>>>>>>>>> handle the multiple AS scenario (likely to occur then). >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> We are drifting away from the original problem space. >>>>>>>>>> >>>>>>>>>> - My original mention was about the "POST" request, that >>>>>>>>>> subsumes that the "AS" is a "Server". Designing a new protoco= l, we cannot >>>>>>>>>> afford this limitation. >>>>>>>>>> - I just mentioned SIOP to show a known and closed example? >>>>>>>>>> Let us not focus on the device local discovery scheme (like o= penid:) for >>>>>>>>>> now. >>>>>>>>>> - As capability of holding private keys on user device >>>>>>>>>> evolves, server-based issuing of token will be fading out giv= ing way to >>>>>>>>>> device local generation of token. >>>>>>>>>> >>>>>>>>>> While designing GNAP, let us assume the AS-Role can be exercised >>>>>>>>>> on a user device and design the protocol to honor that. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> /Francis >>>>>>>>>> ------------------------------ >>>>>>>>>> *From:* TXAuth on behalf of Dick Hardt >>>>>>>>>> >>>>>>>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>>>>>>>> *To:* Tom Jones >>>>>>>>>> *Cc:* Fabien Imbault ; Denis < >>>>>>>>>> denis.ietf@free.fr>; GNAP Mailing List ; Justin >>>>>>>>>> Richer >>>>>>>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>>>>>>> >>>>>>>>>> Got it. >>>>>>>>>> >>>>>>>>>> So web apps invoke a openid: deep link and hope there is an app >>>>>>>>>> to handle the openid: scheme? ... and that it is the user's wall= et rather >>>>>>>>>> than some malware that has registered openid: on the mobile devi= ce? >>>>>>>>>> >>>>>>>>>> A native app can attempt to open a deep link associated with an >>>>>>>>>> app, and will fail if the app is not there. If the app is there,= it will be >>>>>>>>>> opened, so this can't be used to silently test if an app is pres= ent, but it >>>>>>>>>> does allow a native app to provide an alternative experience if = an app is >>>>>>>>>> not present. I don't think this works with custom schemes ... an= d I don't >>>>>>>>>> know how it could work from a web app on the phone with the curr= ent Safari >>>>>>>>>> APIs. >>>>>>>>>> >>>>>>>>>> Apple warns against using custom schemes [1] ... but perhaps the= y >>>>>>>>>> can be convinced to make openid: a managed scheme similar to mai= lto:, >>>>>>>>>> tel:, sms:, facetime: ? >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> https://developer.apple.com/documentation/xcode/allowing_apps_an= d_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_ap= p >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> =E1=90=A7 >>>>>>>>>> >>>>>>>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> You are - that is not standard which is opeind:// >>>>>>>>>> This is the one step that still needs to be optimized for SIOP t= o >>>>>>>>>> have good UX. >>>>>>>>>> Peace ..tom >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Tom >>>>>>>>>> >>>>>>>>>> I watched your video (I watched at 2X speed) >>>>>>>>>> >>>>>>>>>> Looks like the employment website app that is using >>>>>>>>>> localhost:8765 to communicate with the wallet. Am I correct? >>>>>>>>>> >>>>>>>>>> /Dick >>>>>>>>>> =E1=90=A7 >>>>>>>>>> >>>>>>>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones < >>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> Well, here's a demo. Note that in this case the AS is not online >>>>>>>>>> all of the time, so it is really implicit flow and the OIDC id-t= oken comes >>>>>>>>>> from the siop device directly. >>>>>>>>>> (whether this is front-channel or back channel is no longer an >>>>>>>>>> interesting question.) >>>>>>>>>> Now if an always-on AS is required, that is possible, but >>>>>>>>>> probably beyond the scope of this effort and would require somet= hing like >>>>>>>>>> an agent-in-the-sky (with diamonds). >>>>>>>>>> here is the link to the 9 min video https://youtu.be >>>>>>>>>> /Tq4hw7X5SW0 >>>>>>>>>> >>>>>>>>>> Peace ..tom >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Ultimately, in most situations like these in the real world, the >>>>>>>>>> hurdle isn=E2=80=99t technical compatibility so much as it is tr= ust compatibility. >>>>>>>>>> The RP (client) needs to have some incentive to trust the assert= ions and >>>>>>>>>> identity information that=E2=80=99s coming from the AS. The same= is true for an RS >>>>>>>>>> trusting tokens from the AS. The hard question is less =E2=80=9C= how=E2=80=9D to do that >>>>>>>>>> (which SSI answers), but more =E2=80=9Cwhy=E2=80=9D to do that (= which SSI doesn=E2=80=99t answer >>>>>>>>>> very well, because it=E2=80=99s a hard question). >>>>>>>>>> >>>>>>>>>> Still: it=E2=80=99s definitely a question about how to support t= his =E2=80=9CAS >>>>>>>>>> on device=E2=80=9D element. We=E2=80=99ve got the start of it mo= re than OAuth2/OIDC have by >>>>>>>>>> allowing the bootstrap of the process from a starting call: the = interaction >>>>>>>>>> and continuation URIs handed back by the AS don=E2=80=99t need t= o be the same URIs >>>>>>>>>> that the client starts with, so just like SIOP the process can s= tart in >>>>>>>>>> HTTP and potentially move to other communication channels. A maj= or >>>>>>>>>> difference is that we aren=E2=80=99t dependent on the assumption= that the user will >>>>>>>>>> always be in a browser at some stage, and so the whole raft of >>>>>>>>>> front-channel messages that SIOP relies on doesn=E2=80=99t fly. = That said, we=E2=80=99ve >>>>>>>>>> got an opportunity to more explicitly open up alternative commun= ication >>>>>>>>>> channels here, and that=E2=80=99s something I=E2=80=99d like to = see engineered, even if >>>>>>>>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete pr= oposal as to how that would >>>>>>>>>> work over specific protocols, starting with what we=E2=80=99ve g= ot today. >>>>>>>>>> >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>> >>>>>>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> Hi Denis, hi Francis, >>>>>>>>>> >>>>>>>>>> At some point integration with SSI (on the authentication side) >>>>>>>>>> will probably occur, including amongst other possibilities SIOP = (since they >>>>>>>>>> work with OpenID a part of the work will probably be made easier= ). >>>>>>>>>> >>>>>>>>>> That being said, Denis is right. It's not an AS. Technically it'= s >>>>>>>>>> entirely possible to rely on a decentralized wallet (for instanc= e on your >>>>>>>>>> phone) and a centralized AS. I know of a few studies on how to d= ecentralize >>>>>>>>>> the AS itself (for instance >>>>>>>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-0= 2 >>>>>>>>>> ). >>>>>>>>>> Maybe it exists, but I'm still looking for real scenarios (or >>>>>>>>>> even architectures) where an AS is deployed directly on a phone,= and under >>>>>>>>>> the sole authority of the RO, while being compatible with the re= st of the >>>>>>>>>> world. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote= : >>>>>>>>>> >>>>>>>>>> Hello Francis, >>>>>>>>>> >>>>>>>>>> See two comments in line. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> B) Current Document >>>>>>>>>> >>>>>>>>>> Roles description shall not hold any assumption on the physical >>>>>>>>>> structure of the party fulfilling the roles. >>>>>>>>>> [FI] not sure what you mean >>>>>>>>>> >>>>>>>>>> [FP] for example, we assume the AS is a server! In most SSI >>>>>>>>>> based use cases, the AS will be running on the user device. See = SIOP ( >>>>>>>>>> https://identity.foundation/did-siop/). >>>>>>>>>> >>>>>>>>>> I browsed through the two drafts, i.e. : >>>>>>>>>> >>>>>>>>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, >>>>>>>>>> data model, and representations W3C Working Draft 08 November= 2020 >>>>>>>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF >>>>>>>>>> Working Group Draft >>>>>>>>>> >>>>>>>>>> At no place within these two documents, it is possible to imagin= e >>>>>>>>>> that "the AS will be running on the user device". >>>>>>>>>> >>>>>>>>>> From section 3 of the DIF Working Group Draft: >>>>>>>>>> >>>>>>>>>> "Unlike the OIDC Authorization Code Flow as per >>>>>>>>>> [OIDC.Core], the SIOP will not return an access token to the RP"= . >>>>>>>>>> >>>>>>>>>> An Identity Wallet is not an AS. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Roles: >>>>>>>>>> -> grant endpoint of the AS: Why is this a post request? This >>>>>>>>>> eliminates the chance of having user device hosted AS (no server= ). >>>>>>>>>> [FI] what would you propose instead? >>>>>>>>>> Would also be interested to understand better the deployment >>>>>>>>>> model when there is no server. That's something that was discuss= ed several >>>>>>>>>> times but I'm still missing the underlying architecture and use = case. >>>>>>>>>> >>>>>>>>>> [FP] See above (SIOP). There will be a lot of identity wallets >>>>>>>>>> operated on end user device. >>>>>>>>>> >>>>>>>>>> See the above comment. Please, do not confuse an Identity Wallet >>>>>>>>>> with an Authentication Server (AS). >>>>>>>>>> >>>>>>>>>> Denis >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it >>>>>>>>>> authorize the request or the access to a resource? >>>>>>>>>> [FI] yes, we should make the wording clearer >>>>>>>>>> >>>>>>>>>> Missing Section Interactions: >>>>>>>>>> --> This section shall introduce the notion of interaction befor= e >>>>>>>>>> we start listing interaction types. >>>>>>>>>> [FI] yes >>>>>>>>>> >>>>>>>>>> Interaction Types: >>>>>>>>>> --> I prefer a classification with Redirect, Decoupled and >>>>>>>>>> Embedded is. In the draft, we have one redirect and 2 decouple i= nteractions >>>>>>>>>> and nothing else. >>>>>>>>>> [FI] this should be handled as a specific discussion item. As a >>>>>>>>>> reminder, how would you define embedded? >>>>>>>>>> >>>>>>>>>> In practice there's at least these modes: >>>>>>>>>> - redirect and redirect back >>>>>>>>>> - redirect to different browser or device >>>>>>>>>> - user code >>>>>>>>>> - CIBA >>>>>>>>>> >>>>>>>>>> [FP] This classification is limited. >>>>>>>>>> >>>>>>>>>> - Redirect: same device, same or different user agents >>>>>>>>>> (browser, mobile app, desktop app, ...) >>>>>>>>>> - Decoupled: different devices >>>>>>>>>> - Embedded : RC carries RO authorization to AS >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Resource Access Request vs. Resource Request >>>>>>>>>> --> Both are mixed up. No clarification of the context of each >>>>>>>>>> section. >>>>>>>>>> [FI] could you clarify what you'd expect. Btw on this topic, >>>>>>>>>> there's a more general discussion on whether we should make a di= stinction >>>>>>>>>> or not. >>>>>>>>>> >>>>>>>>>> =E2=80=8B[FP]: Here: >>>>>>>>>> >>>>>>>>>> - Resource Access Request: Requesting Access to a resource. >>>>>>>>>> Response is an access token (or any type of grant) >>>>>>>>>> - Resource Request: Request the resource. Response is the >>>>>>>>>> resource (or a corresponding execution) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Token Content Negotiation >>>>>>>>>> --> Not expressed as such. This is central to GNAP and not >>>>>>>>>> represented enough in the document. >>>>>>>>>> [FI] right. This should be a specific discussion item. >>>>>>>>>> >>>>>>>>>> Requesting "User" Information >>>>>>>>>> we identify two types of users: RQ and RO. It will be better not >>>>>>>>>> to refer to a user in this draft, but either to a RQ or an RO. >>>>>>>>>> [FI] yes that would avoid potential misunderstandings. Although >>>>>>>>>> in the end, people will translate RQ into user or end-user most = of the >>>>>>>>>> time. Cf in definition, currently we have Requesting Party (RQ, >>>>>>>>>> aka "user") >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Interaction Again >>>>>>>>>> -> For each interaction type, we will have to describe the >>>>>>>>>> protocol flow and the nature and behavior of involved Roles (Par= ties), >>>>>>>>>> Elements, Requests. >>>>>>>>>> [FI] yes >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [FP] Will these and into tickets? >>>>>>>>>> >>>>>>>>>> Best regards. >>>>>>>>>> /Francis >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> TXAuth mailing list >>>>>>>>>> TXAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> TXAuth mailing list >>>>>>>>>> TXAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> TXAuth mailing list >>>>>>>>>> TXAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> TXAuth mailing list >>>>>>>>>> TXAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>> >>>>>>>>>> >>>>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> >>> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --00000000000055a50f05ba886f7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i assumed that the wallet (aka AS) needed to be a native a= pp, not a PWA (which can come from a traditional web server).
There are= folks, lke Kim C, who are working on a PWA, but i agree the blocks there s= eem to be large.
THe blocks on a native app are simple, easy to d= escribe, and easy to ask the browser guys to fix. Not sure if they care tho= .
I have trouble seeing a path to GNAP adoption for retail custom= ers w/o some browser support.
That's why i am mostly=C2=A0sil= ent here.

Be the change you= want to see in the world ..tom


On = Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Fair enough. But= loopback limits a lot what you can do... Just for debug it's a pain.= =C2=A0
But as soon as you try more, it's a bit crazy. = Fun to test ipv6 (luckily supported by my ISP) and ddns. But it feels reall= y hacky.=C2=A0
Also deployment is a pain, compared t= o a traditional webserver.=C2=A0

=
Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:2= 0, Tom Jones <thomasclinganjo= nes@gmail.com> a =C3=A9crit=C2=A0:
doesn't work very well on wi= ndows uwp. works fine on smartphones
Be the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:18 AM Justin Rich= er <jricher@mit.edu> wro= te:
OK, tha= nks =E2=80=94 in that case, there are no changes at all to GNAP, which is a= lready HTTP driven. The harder parts tend to be where you can=E2=80=99t (or= don=E2=80=99t want to) use something like that.

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

On Feb 4, 2021,= at 2:16 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

yes, loopback

Be the change= you want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:01 AM Justin Richer <jricher@mit.edu> wrote:
Tom, can you expand on how exactly th= e back-channel =C2=A0communication works between on-device components? Do y= ou use HTTP locally?

Thanks,
=C2=A0=E2=80=94 J= ustin

On Feb 4, 2021, at 1:03 PM= , Tom Jones <thoma= sclinganjones@gmail.com> wrote:

Justi= n's analysis of use of the front channel is misleading.
It could eq= ually be argued that what i have done is installed an AS on the phone and t= he communications with it & the PR is back channel.
Basically= the point is that the old OIDC paradigms are no longer valid.
Be the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbaul= t <fabien.imbault@gmai= l.com> wrote:
Yes, issue (#168)=C2=A0message based interaction / DI= DComm is a tentative alternative mecanism for the interaction part. Not sur= e how that would work in details=C2=A0though, prototyping will probably hel= p here.
Token delivery=C2=A0through continuation seems fine to me. The = client will probably have to wait for the next polling before it receives a= token issued as the result of an asynchronous interaction, but that's = not a big issue.

But the AS on the phone seems lik= e a harder nut to crack, at least at first sight. I think that would be awe= some, but it gives me headaches, so I think I'll work on easier stuff r= ight now ;-)

Fabien=C2=A0=C2=A0
On Thu, F= eb 4, 2021 at 4:30 PM Justin Richer <jricher@mit.edu> wrote:
One of the biggest drawbacks of the current app-c= entric approaches in OIDC (self-issued OP, or SIOP) is that they depend on = using the front channel and browser redirects to pass everything, which is = something that GNAP is deliberately getting away from by starting in the ba= ck channel.

That said, once a request is kicked off in G= NAP, the interaction and fulfillment can happen through any number of means= . Part of the work that=E2=80=99s being done with the =E2=80=9Cinteraction= =E2=80=9D section is going to help facilitate this, and I think that there = are some other potential branches here.

Token deli= very is where things get extra weird though =E2=80=94 we are explicitly not= delivering tokens in the front channel in the core of GNAP, we=E2=80=99re = using the response from the continuation API. One idea (that isn=E2=80=99t = particularly well thought out and hasn=E2=80=99t been implemented at all) i= s to have an extension declare an alternative response from the =E2=80=9Cco= ntinue=E2=80=9D section that=E2=80=99s defined today, which points to the G= NPA continuation API. If an extension defines some alternative way to deliv= er tokens, that could live alongside a continuation API and the client coul= d indicate support for it in its initial request.

= In any event, alternative interaction and delivery methods are important, a= nd even if we aren=E2=80=99t going to support every last one of them direct= ly, the protocol design should at least be aware of them.

=C2=A0=E2=80=94 Justin

O= n Feb 4, 2021, at 8:35 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

=
Hi Tom,=C2=A0

Sure, any experience on t= hat would be greatly appreciated, we're calling for help here (the poin= t being that I suspect what they're doing is not trivial).
Fabien

On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.c= om> wrote:
I've had such an app working for over a year. There= are issues which are being addressed by the browser Interaction team of oi= dc.

thx ..Tom (mobile)

On Thu, Feb 4, 2021, 3:12 AM Fabien= Imbault <fabien.imbau= lt@gmail.com> wrote:
Hi Francis,=C2=A0

I've = tried a few things with regards to using the AS on a phone, but it's re= ally quite=C2=A0complex.=C2=A0

Making that run on = a phone comes with quite a bit of trouble. The most difficult part if that = we'd need to use a secure element, but just installing and hosting a ht= tp server securely is not a standard setup at all. I suggest interested peo= ple step in to work on this, as we already have a lot of work for the (more= usual) server case and already handle a privacy preserving scheme.=C2=A0

Please let us know what you think.

Cheers,
Fabien=C2=A0

On Tue, Nov 24, 2020 at 5:55 A= M Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,

I've thought a bit more to what y= ou said. I think I'll give it a try as a separate experiment (in code, = not in theory). Not that I would expect it to be included in GNAP, but I ki= nd of like the idea :-)

= The direct impact for GNAP would be to think about multiple ASs.=C2=A0

Will let you know.=C2=A0

Fabien=C2=A0


<= div class=3D"gmail_quote">
Le mer. 18 = nov. 2020 =C3=A0 13:06, Francis Pouatcha <fpo@adorsys.de> a =C3=A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"gmail-m_-6718184999452512077m_-3004232231493229381m_-886255095867453130= 6m_4552653984562635461m_387929924441527190m_6662104191003806385gmail-m_-542= 839070341023388gmail-m_-6176056956474019294gmail-m_-3037161202240578685gmai= l-m_-7520389457378808664gmail-m_-3342024782330569254m_8014700032835912204gm= ail-m_142651873244800559m_8348797445460806175LPlnk338391" rel=3D"noreferrer= noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target= =3D"_blank">https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: t= xauth@ietf.org <txauth@ietf.org>; Dick Hardt <dick.hardt@gmail.com>; = Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@adorsys.de> wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-bounces@ietf.org> on b= ehalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@fr= ee.fr>; GNAP Mailing List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclin= ganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.c= om> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomascling= anjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.be<= /span>/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu= > wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com= > wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https:/= /tools.ietf.org/html/draft-hardjono-oauth-decentralized-02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr>= ; wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= =E2=80=8B= [FP]: Here:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


--
TXAuth mailing list
TXAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/txauth
--00000000000055a50f05ba886f7a-- From nobody Thu Feb 4 12:45:11 2021 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 A0E993A17E8 for ; Thu, 4 Feb 2021 12:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, PDS_SHORTFWD_URISHRT_QP=1.498, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 WRIYLSnOEj_8 for ; Thu, 4 Feb 2021 12:45:05 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92A63A17E6 for ; Thu, 4 Feb 2021 12:45:04 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 114Kj14M002486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 4 Feb 2021 15:45:02 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BAAD65CC-57A2-4826-B3B7-A06F2A00E596" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 4 Feb 2021 15:45:01 -0500 In-Reply-To: Cc: Fabien Imbault , txauth gnap To: Tom Jones References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> <77D1AE7B-076F-4095-8FAA-7C35D74614BD@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 20:45:10 -0000 --Apple-Mail=_BAAD65CC-57A2-4826-B3B7-A06F2A00E596 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tom, what additional functionality do you see that a browser would need = to support in order for GNAP to be adopted? For the elements of the core = protocol today, nothing is needed to change within the browsers =E2=80=94 = everything is built on existing functions. GNAP uses browsers as a tool, = and I would argue depends on them even less so than OAuth 2 does. = Extensions could use browser functionality, like using CHAPI to pass = interaction elements, but the core protocol functions on vanilla = browsers today. =E2=80=94 Justin > On Feb 4, 2021, at 3:20 PM, Tom Jones = wrote: >=20 > i assumed that the wallet (aka AS) needed to be a native app, not a = PWA (which can come from a traditional web server). > There are folks, lke Kim C, who are working on a PWA, but i agree the = blocks there seem to be large. > THe blocks on a native app are simple, easy to describe, and easy to = ask the browser guys to fix. Not sure if they care tho. > I have trouble seeing a path to GNAP adoption for retail customers w/o = some browser support. > That's why i am mostly silent here. >=20 > Be the change you want to see in the world ..tom >=20 >=20 > On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault = > wrote: > Fair enough. But loopback limits a lot what you can do... Just for = debug it's a pain.=20 > But as soon as you try more, it's a bit crazy. Fun to test ipv6 = (luckily supported by my ISP) and ddns. But it feels really hacky.=20 > Also deployment is a pain, compared to a traditional webserver.=20 >=20 > Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones = > a = =C3=A9crit : > doesn't work very well on windows uwp. works fine on smartphones > Be the change you want to see in the world ..tom >=20 >=20 > On Thu, Feb 4, 2021 at 11:18 AM Justin Richer > wrote: > OK, thanks =E2=80=94 in that case, there are no changes at all to = GNAP, which is already HTTP driven. The harder parts tend to be where = you can=E2=80=99t (or don=E2=80=99t want to) use something like that. >=20 > =E2=80=94 Justin >=20 >> On Feb 4, 2021, at 2:16 PM, Tom Jones > wrote: >>=20 >> yes, loopback >>=20 >> Be the change you want to see in the world ..tom >>=20 >>=20 >> On Thu, Feb 4, 2021 at 11:01 AM Justin Richer > wrote: >> Tom, can you expand on how exactly the back-channel communication = works between on-device components? Do you use HTTP locally? >>=20 >> Thanks, >> =E2=80=94 Justin >>=20 >>> On Feb 4, 2021, at 1:03 PM, Tom Jones > wrote: >>>=20 >>> Justin's analysis of use of the front channel is misleading. >>> It could equally be argued that what i have done is installed an AS = on the phone and the communications with it & the PR is back channel. >>> Basically the point is that the old OIDC paradigms are no longer = valid. >>> Be the change you want to see in the world ..tom >>>=20 >>>=20 >>> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault = > wrote: >>> Yes, issue (#168) message based interaction / DIDComm is a tentative = alternative mecanism for the interaction part. Not sure how that would = work in details though, prototyping will probably help here. >>> Token delivery through continuation seems fine to me. The client = will probably have to wait for the next polling before it receives a = token issued as the result of an asynchronous interaction, but that's = not a big issue. >>>=20 >>> But the AS on the phone seems like a harder nut to crack, at least = at first sight. I think that would be awesome, but it gives me = headaches, so I think I'll work on easier stuff right now ;-) >>>=20 >>> Fabien =20 >>>=20 >>> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer > wrote: >>> One of the biggest drawbacks of the current app-centric approaches = in OIDC (self-issued OP, or SIOP) is that they depend on using the front = channel and browser redirects to pass everything, which is something = that GNAP is deliberately getting away from by starting in the back = channel. >>>=20 >>> That said, once a request is kicked off in GNAP, the interaction and = fulfillment can happen through any number of means. Part of the work = that=E2=80=99s being done with the =E2=80=9Cinteraction=E2=80=9D section = is going to help facilitate this, and I think that there are some other = potential branches here. >>>=20 >>> Token delivery is where things get extra weird though =E2=80=94 we = are explicitly not delivering tokens in the front channel in the core of = GNAP, we=E2=80=99re using the response from the continuation API. One = idea (that isn=E2=80=99t particularly well thought out and hasn=E2=80=99t = been implemented at all) is to have an extension declare an alternative = response from the =E2=80=9Ccontinue=E2=80=9D section that=E2=80=99s = defined today, which points to the GNPA continuation API. If an = extension defines some alternative way to deliver tokens, that could = live alongside a continuation API and the client could indicate support = for it in its initial request. >>>=20 >>> In any event, alternative interaction and delivery methods are = important, and even if we aren=E2=80=99t going to support every last one = of them directly, the protocol design should at least be aware of them. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault = > wrote: >>>>=20 >>>> Hi Tom,=20 >>>>=20 >>>> Sure, any experience on that would be greatly appreciated, we're = calling for help here (the point being that I suspect what they're doing = is not trivial). >>>>=20 >>>> Fabien >>>>=20 >>>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones = > = wrote: >>>> I've had such an app working for over a year. There are issues = which are being addressed by the browser Interaction team of oidc. >>>>=20 >>>> thx ..Tom (mobile) >>>>=20 >>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault = > wrote: >>>> Hi Francis,=20 >>>>=20 >>>> I've tried a few things with regards to using the AS on a phone, = but it's really quite complex.=20 >>>>=20 >>>> Making that run on a phone comes with quite a bit of trouble. The = most difficult part if that we'd need to use a secure element, but just = installing and hosting a http server securely is not a standard setup at = all. I suggest interested people step in to work on this, as we already = have a lot of work for the (more usual) server case and already handle a = privacy preserving scheme.=20 >>>>=20 >>>> Please let us know what you think. >>>>=20 >>>> Cheers, >>>> Fabien=20 >>>>=20 >>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault = > wrote: >>>> Hi Francis, >>>>=20 >>>> I've thought a bit more to what you said. I think I'll give it a = try as a separate experiment (in code, not in theory). Not that I would = expect it to be included in GNAP, but I kind of like the idea :-) >>>>=20 >>>> The direct impact for GNAP would be to think about multiple ASs.=20 >>>>=20 >>>> Will let you know.=20 >>>>=20 >>>> Fabien=20 >>>>=20 >>>>=20 >>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha > a =C3=A9crit : >>>> It would be nice if the protocol was designed at many layers of = abstraction. >>>>=20 >>>> The first layer shall design abstract protocol flows, without = specification of the mode and mechanism of interaction. >>>> The second layer can instantiate the first layer for dedicated = interaction. Here we can talk http, we can define interactions that = presume server based token generation, we can define interaction that = run on user device based token generation. >>>> This is also the fundament of the structure I proposed for the spec = (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30 = ). >>>>=20 >>>> /Francis >>>>=20 >>>> From: Fabien Imbault > >>>> Sent: Wednesday, November 18, 2020 6:35 AM >>>> To: Francis Pouatcha > >>>> Cc: txauth@ietf.org >; Dick Hardt >; Tom Jones >; Denis >; Justin Richer > >>>> Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>> =20 >>>> Would make sense, but not so easy as we rely heavily on HTTP. Hence = the discussion about deep links and so on. >>>>=20 >>>> An alternative might be provided by wasm/wasi (running a local = sandbox on your phone, for your own AS), but it's really early stage. = This also poses another question that Denis has put forward, i.e. how do = we handle the multiple AS scenario (likely to occur then).=20 >>>>=20 >>>> Fabien=20 >>>>=20 >>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha > wrote: >>>> We are drifting away from the original problem space. >>>> My original mention was about the "POST" request, that subsumes = that the "AS" is a "Server". Designing a new protocol, we cannot afford = this limitation. >>>> I just mentioned SIOP to show a known and closed example? Let us = not focus on the device local discovery scheme (like openid:) for now. >>>> As capability of holding private keys on user device evolves, = server-based issuing of token will be fading out giving way to device = local generation of token. >>>> While designing GNAP, let us assume the AS-Role can be exercised on = a user device and design the protocol to honor that. >>>>=20 >>>> Best regards, >>>> /Francis >>>> From: TXAuth > on behalf of Dick Hardt = > >>>> Sent: Tuesday, November 17, 2020 1:28 PM >>>> To: Tom Jones > >>>> Cc: Fabien Imbault >; Denis >; GNAP Mailing List >; Justin Richer > >>>> Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>> =20 >>>> Got it.=20 >>>>=20 >>>> So web apps invoke a openid: deep link and hope there is an app to = handle the openid: scheme? ... and that it is the user's wallet rather = than some malware that has registered openid: on the mobile device? >>>>=20 >>>> A native app can attempt to open a deep link associated with an = app, and will fail if the app is not there. If the app is there, it will = be opened, so this can't be used to silently test if an app is present, = but it does allow a native app to provide an alternative experience if = an app is not present. I don't think this works with custom schemes ... = and I don't know how it could work from a web app on the phone with the = current Safari APIs. >>>>=20 >>>> Apple warns against using custom schemes [1] ... but perhaps they = can be convinced to make openid: a managed scheme similar to mailto:, = tel:, sms:, facetime: ? >>>>=20 >>>> [1] = https://developer.apple.com/documentation/xcode/allowing_apps_and_websites= _to_link_to_your_content/defining_a_custom_url_scheme_for_your_app = >>>>=20 >>>>=20 >>>> =E1=90=A7 >>>>=20 >>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones = > = wrote: >>>> You are - that is not standard which is opeind:// >>>> This is the one step that still needs to be optimized for SIOP to = have good UX. >>>> Peace ..tom >>>>=20 >>>>=20 >>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt > wrote: >>>> Hi Tom >>>>=20 >>>> I watched your video (I watched at 2X speed) >>>>=20 >>>> Looks like the employment website app that is using localhost:8765 = to communicate with the wallet. Am I correct? >>>>=20 >>>> /Dick=20 >>>> =E1=90=A7 >>>>=20 >>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones = > = wrote: >>>> Well, here's a demo. Note that in this case the AS is not online = all of the time, so it is really implicit flow and the OIDC id-token = comes from the siop device directly. >>>> (whether this is front-channel or back channel is no longer an = interesting question.) >>>> Now if an always-on AS is required, that is possible, but probably = beyond the scope of this effort and would require something like an = agent-in-the-sky (with diamonds). >>>> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 = >>>> Peace ..tom >>>>=20 >>>>=20 >>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer > wrote: >>>> Ultimately, in most situations like these in the real world, the = hurdle isn=E2=80=99t technical compatibility so much as it is trust = compatibility. The RP (client) needs to have some incentive to trust the = assertions and identity information that=E2=80=99s coming from the AS. = The same is true for an RS trusting tokens from the AS. The hard = question is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), = but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t = answer very well, because it=E2=80=99s a hard question). >>>>=20 >>>> Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of = it more than OAuth2/OIDC have by allowing the bootstrap of the process = from a starting call: the interaction and continuation URIs handed back = by the AS don=E2=80=99t need to be the same URIs that the client starts = with, so just like SIOP the process can start in HTTP and potentially = move to other communication channels. A major difference is that we = aren=E2=80=99t dependent on the assumption that the user will always be = in a browser at some stage, and so the whole raft of front-channel = messages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve= got an opportunity to more explicitly open up alternative communication = channels here, and that=E2=80=99s something I=E2=80=99d like to see = engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a = concrete proposal as to how that would work over specific protocols, = starting with what we=E2=80=99ve got today.=20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault = > wrote: >>>>>=20 >>>>> Hi Denis, hi Francis,=20 >>>>>=20 >>>>> At some point integration with SSI (on the authentication side) = will probably occur, including amongst other possibilities SIOP (since = they work with OpenID a part of the work will probably be made easier).=20= >>>>>=20 >>>>> That being said, Denis is right. It's not an AS. Technically it's = entirely possible to rely on a decentralized wallet (for instance on = your phone) and a centralized AS. I know of a few studies on how to = decentralize the AS itself (for instance = https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02 = ). >>>>> Maybe it exists, but I'm still looking for real scenarios (or even = architectures) where an AS is deployed directly on a phone, and under = the sole authority of the RO, while being compatible with the rest of = the world.=20 >>>>>=20 >>>>> Cheers, >>>>> Fabien >>>>>=20 >>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis > wrote: >>>>> Hello Francis, >>>>>=20 >>>>> See two comments in line. >>>>>=20 >>>>>>=20 >>>>>> B) Current Document >>>>>>=20 >>>>>> Roles description shall not hold any assumption on the physical = structure of the party fulfilling the roles. >>>>>> [FI] not sure what you mean >>>>>> [FP] for example, we assume the AS is a server! In most SSI = based use cases, the AS will be running on the user device. See SIOP = (https://identity.foundation/did-siop/ = ). >>>>> I browsed through the two drafts, i.e. : >>>>>=20 >>>>> Decentralized Identifiers (DIDs) v1.0 Core architecture, data = model, and representations W3C Working Draft 08 November 2020 >>>>> Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft >>>>> At no place within these two documents, it is possible to imagine = that "the AS will be running on the user device". >>>>>=20 >>>>> =46rom section 3 of the DIF Working Group Draft: >>>>>=20 >>>>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], = the SIOP will not return an access token to the RP". >>>>>=20 >>>>> An Identity Wallet is not an AS.=20 >>>>>=20 >>>>>>=20 >>>>>> Roles:=20 >>>>>> -> grant endpoint of the AS: Why is this a post request? This = eliminates the chance of having user device hosted AS (no server). >>>>>> [FI] what would you propose instead? >>>>>> Would also be interested to understand better the deployment = model when there is no server. That's something that was discussed = several times but I'm still missing the underlying architecture and use = case. >>>>>> [FP] See above (SIOP). There will be a lot of identity wallets = operated on end user device. >>>>> See the above comment. Please, do not confuse an Identity Wallet = with an Authentication Server (AS). >>>>>=20 >>>>> Denis >>>>>=20 >>>>>>=20 >>>>>> -> Resource Owner (RO) : Authorizes the request? Does it = authorize the request or the access to a resource? >>>>>> [FI] yes, we should make the wording clearer >>>>>>=20 >>>>>> Missing Section Interactions: >>>>>> --> This section shall introduce the notion of interaction before = we start listing interaction types. >>>>>> [FI] yes=20 >>>>>>=20 >>>>>> Interaction Types: >>>>>> --> I prefer a classification with Redirect, Decoupled and = Embedded is. In the draft, we have one redirect and 2 decouple = interactions and nothing else. >>>>>> [FI] this should be handled as a specific discussion item. As a = reminder, how would you define embedded? >>>>>>=20 >>>>>> In practice there's at least these modes: >>>>>> - redirect and redirect back >>>>>> - redirect to different browser or device >>>>>> - user code >>>>>> - CIBA >>>>>> [FP] This classification is limited. >>>>>> Redirect: same device, same or different user agents (browser, = mobile app, desktop app, ...) >>>>>> Decoupled: different devices >>>>>> Embedded : RC carries RO authorization to AS >>>>>>=20 >>>>>>=20 >>>>>> Resource Access Request vs. Resource Request >>>>>> --> Both are mixed up. No clarification of the context of each = section. >>>>>> [FI] could you clarify what you'd expect. Btw on this topic, = there's a more general discussion on whether we should make a = distinction or not.=20 >>>>>> =E2=80=8B[FP]: Here: >>>>>> Resource Access Request: Requesting Access to a resource. = Response is an access token (or any type of grant) >>>>>> Resource Request: Request the resource. Response is the resource = (or a corresponding execution) >>>>>>=20 >>>>>> Token Content Negotiation >>>>>> --> Not expressed as such. This is central to GNAP and not = represented enough in the document. >>>>>> [FI] right. This should be a specific discussion item.=20 >>>>>>=20 >>>>>> Requesting "User" Information >>>>>> we identify two types of users: RQ and RO. It will be better not = to refer to a user in this draft, but either to a RQ or an RO. >>>>>> [FI] yes that would avoid potential misunderstandings. Although = in the end, people will translate RQ into user or end-user most of the = time. Cf in definition, currently we have Requesting Party (RQ, aka = "user") >>>>>>=20 >>>>>>=20 >>>>>> Interaction Again >>>>>> -> For each interaction type, we will have to describe the = protocol flow and the nature and behavior of involved Roles (Parties), = Elements, Requests. >>>>>> [FI] yes =20 >>>>>>=20 >>>>>> [FP] Will these and into tickets? >>>>>>=20 >>>>>> Best regards. >>>>>> /Francis >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> --=20 >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>> --=20 >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>=20 >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_BAAD65CC-57A2-4826-B3B7-A06F2A00E596 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Tom, = what additional functionality do you see that a browser would need to = support in order for GNAP to be adopted? For the elements of the core = protocol today, nothing is needed to change within the browsers =E2=80=94 = everything is built on existing functions. GNAP uses browsers as a tool, = and I would argue depends on them even less so than OAuth 2 does. = Extensions could use browser functionality, like using CHAPI to pass = interaction elements, but the core protocol functions on vanilla = browsers today.

 =E2=80=94 Justin

On Feb = 4, 2021, at 3:20 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

i assumed that the wallet (aka = AS) needed to be a native app, not a PWA (which can come from a = traditional web server).
There are folks, lke Kim C, who = are working on a PWA, but i agree the blocks there seem to be = large.
THe blocks on a native app are simple, easy = to describe, and easy to ask the browser guys to fix. Not sure if they = care tho.
I have trouble seeing a path to GNAP = adoption for retail customers w/o some browser support.
That's why i am mostly silent here.

Be the change you want to see in the world = ..tom


On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
Fair = enough. But loopback limits a lot what you can do... Just for debug it's = a pain. 
But as soon as you try more, = it's a bit crazy. Fun to test ipv6 (luckily supported by my ISP) and = ddns. But it feels really hacky. 
Also deployment is a pain, compared to a traditional = webserver. 

Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 = 20:20, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit :
doesn't = work very well on windows uwp. works fine on smartphones
Be the change you = want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:18 AM Justin = Richer <jricher@mit.edu> wrote:
OK, thanks =E2=80= =94 in that case, there are no changes at all to GNAP, which is already = HTTP driven. The harder parts tend to be where you can=E2=80=99t (or = don=E2=80=99t want to) use something like that.

 =E2=80=94 Justin

On Feb 4, 2021, at 2:16 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

yes, loopback

Be the change you want to see in the world = ..tom


On Thu, Feb 4, 2021 at 11:01 AM Justin Richer = <jricher@mit.edu> wrote:
Tom, can you = expand on how exactly the back-channel  communication works between = on-device components? Do you use HTTP locally?

Thanks,
 =E2=80= =94 Justin

On Feb 4, 2021, at 1:03 PM, Tom = Jones <thomasclinganjones@gmail.com> = wrote:

Justin's analysis of use of the front channel is = misleading.
It could equally be argued that what i have = done is installed an AS on the phone and the communications with it = & the PR is back channel.
Basically the point = is that the old OIDC paradigms are no longer valid.
Be the change you want to see in the world = ..tom


On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
Yes, = issue (#168) message based interaction / DIDComm is a tentative = alternative mecanism for the interaction part. Not sure how that would = work in details though, prototyping will probably help here.
Token delivery through continuation seems fine to me. = The client will probably have to wait for the next polling before it = receives a token issued as the result of an asynchronous interaction, = but that's not a big issue.

But the AS on the phone seems like a harder nut to crack, at = least at first sight. I think that would be awesome, but it gives me = headaches, so I think I'll work on easier stuff right now ;-)

Fabien  

On Thu, Feb 4, 2021 at 4:30 PM Justin = Richer <jricher@mit.edu> wrote:
One of the = biggest drawbacks of the current app-centric approaches in OIDC = (self-issued OP, or SIOP) is that they depend on using the front channel = and browser redirects to pass everything, which is something that GNAP = is deliberately getting away from by starting in the back channel.

That said, once a = request is kicked off in GNAP, the interaction and fulfillment can = happen through any number of means. Part of the work that=E2=80=99s = being done with the =E2=80=9Cinteraction=E2=80=9D section is going to = help facilitate this, and I think that there are some other potential = branches here.

Token delivery is where things get extra weird though =E2=80=94= we are explicitly not delivering tokens in the front channel in the = core of GNAP, we=E2=80=99re using the response from the continuation = API. One idea (that isn=E2=80=99t particularly well thought out and = hasn=E2=80=99t been implemented at all) is to have an extension declare = an alternative response from the =E2=80=9Ccontinue=E2=80=9D section = that=E2=80=99s defined today, which points to the GNPA continuation API. = If an extension defines some alternative way to deliver tokens, that = could live alongside a continuation API and the client could indicate = support for it in its initial request.

In any event, alternative interaction = and delivery methods are important, and even if we aren=E2=80=99t going = to support every last one of them directly, the protocol design should = at least be aware of them.

 =E2=80=94 Justin

On Feb = 4, 2021, at 8:35 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Tom, 

Sure, any experience on = that would be greatly appreciated, we're calling for help here (the = point being that I suspect what they're doing is not trivial).

Fabien

On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
I've had = such an app working for over a year. There are issues which are being = addressed by the browser Interaction team of oidc.

thx ..Tom (mobile)

On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi = Francis, 

I've = tried a few things with regards to using the AS on a phone, but it's = really quite complex. 

Making that run on a phone comes with = quite a bit of trouble. The most difficult part if that we'd need to use = a secure element, but just installing and hosting a http server securely = is not a standard setup at all. I suggest interested people step in to = work on this, as we already have a lot of work for the (more usual) = server case and already handle a privacy preserving = scheme. 

Please let us know what you think.

Cheers,
Fabien 

On Tue, Nov = 24, 2020 at 5:55 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,

I've thought a bit more to = what you said. I think I'll give it a try as a separate experiment (in = code, not in theory). Not that I would expect it to be included in GNAP, = but I kind of like the idea :-)

The direct impact for GNAP = would be to think about multiple ASs. 

Will let = you know. 

Fabien 


Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha = <fpo@adorsys.de> a =C3=A9crit :
It would be nice if the protocol was designed at many layers of = abstraction.

  • The first layer shall design abstract protocol flows, = without specification of the mode and mechanism of interaction.
  • The second layer can instantiate the first layer for = dedicated interaction. Here we can talk http, we can define interactions = that presume server based token generation, we can define interaction = that run on user device based token generation.
This is also the fundament of the structure I proposed = for the spec (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>; Dick Hardt <dick.hardt@gmail.com>; Tom Jones <thomasclinganjones@gmail.com>; Denis = <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of = draft-ietf-gnap-core-protocol-00
 
Would make sense, but not so easy as we rely = heavily on HTTP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a = local sandbox on your phone, for your own AS), but it's really early = stage. This also poses another question that Denis has put forward, i.e. = how do we handle the multiple AS scenario (likely to occur then). 

Fabien 

On Wed, Nov 18, 2020 at 12:16 PM Francis = Pouatcha <fpo@adorsys.de> wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that = subsumes that the "AS" is a "Server". Designing a new protocol, we = cannot afford this limitation.
  • I just mentioned SIOP = to show a known and closed example? Let us not focus on the device local = discovery scheme (like openid:) for now.
  • As = capability of holding private keys on user device evolves, server-based = issuing of token will be fading out giving way to device local = generation of token.
While designing GNAP, let us assume the AS-Role can be = exercised on a user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@free.fr>; GNAP Mailing List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of = draft-ietf-gnap-core-protocol-00
 
Got it. 

So web apps invoke a openid: deep link and hope there is = an app to handle the openid: scheme? ... and that it is the user's = wallet rather than some malware that has registered openid: on the = mobile device?

A native app can attempt to open a deep link associated = with an app, and will fail if the app is not there. If the app is there, = it will be opened, so this can't be used to silently test if an app is = present, but it does allow a native app to provide an alternative experience if an app is not present. I don't think this = works with custom schemes ... and I don't know how it could work from a = web app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but = perhaps they can be convinced to make openid: a managed scheme similar = to mailto:, tel:, sms:, facetime: ?

[1] https://developer.apple.com/documentation/xcode/allowing_apps_a= nd_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_= app


3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones = <thomasclinganjones@gmail.com> = wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized = for SIOP to have good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt = <dick.hardt@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using = localhost:8765 to communicate with the wallet. Am I correct?

/Dick 
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones = <thomasclinganjones@gmail.com> = wrote:
Well, here's a demo. Note that in this case = the AS is not online all of the time, so it is really implicit flow and = the OIDC id-token comes from the siop device directly.
(whether this is front-channel or back channel is no = longer an interesting question.)
Now if an always-on AS is required, that is possible, = but probably beyond the scope of this effort and would require something = like an agent-in-the-sky (with diamonds).
here is the = link to the 9 min video   https://youtu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin = Richer <jricher@mit.edu> wrote:
=
Ultimately, in most situations like these in the real = world, the hurdle isn=E2=80=99t technical compatibility so much as it is = trust compatibility. The RP (client) needs to have some incentive to = trust the assertions and identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The = hard question is less =E2=80=9Chow=E2=80=9D to do that (which SSI = answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80= =99t answer very well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to = support this =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got = the start of it more than OAuth2/OIDC have by allowing the bootstrap of = the process from a starting call: the interaction and continuation URIs = handed back by the AS don=E2=80=99t need to be the same URIs that the client starts = with, so just like SIOP the process can start in HTTP and potentially = move to other communication channels. A major difference is that we = aren=E2=80=99t dependent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel = messages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve= got an opportunity to more explicitly open up alternative communication = channels here, and that=E2=80=99s something I=E2=80=99d like to see = engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete = proposal as to how that would work over specific protocols, starting = with what we=E2=80=99ve got today. 

 =E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Denis, hi Francis, 

At some point integration with SSI (on the = authentication side) will probably occur, including amongst other = possibilities SIOP (since they work with OpenID a part of the work will = probably be made easier). 

That being said, Denis is right. It's not an AS. = Technically it's entirely possible to rely on a decentralized wallet = (for instance on your phone) and a centralized AS. I know of a few = studies on how to decentralize the AS itself (for instance https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-= 02).
Maybe it exists, but I'm still looking for real = scenarios (or even architectures) where an AS is deployed directly on a = phone, and under the sole authority of the RO, while being compatible = with the rest of the world. 

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
Hello  Francis,

See two comments in line.


B) Current Document

Roles description = shall not hold any assumption on the physical structure of the party = fulfilling the roles.
[FI] = not sure what you mean
 [FP] for example, we assume the AS is a server! In = most SSI based use cases, the AS will be running on the user device. See = SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, = data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile = v0.1. DIF Working Group Draft

At no place within = these two documents, it is possible to imagine that "the AS will be = running on the user device".

=46rom section 3 of the DIF Working Group Draft:

      "Unlike the OIDC Authorization = Code Flow as per [OIDC.Core], the SIOP will not return an access token = to the RP".

An Identity Wallet is not an AS.


Roles: 
-> grant endpoint of the AS: Why = is this a post request? This eliminates the chance of having user device = hosted AS (no server).
[FI] = what would you propose instead?
Would = also be interested to understand better the deployment model when there = is no server. That's something that was discussed several times but I'm = still missing the underlying architecture and use case.
 [FP] See above (SIOP). There will be a lot of identity = wallets operated on end user device.

See the above comment. Please, do not confuse = an Identity Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : = Authorizes the request? Does it authorize the request or the access to a = resource?
[FI] = yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce = the notion of interaction before we start listing interaction = types.
[FI] = yes 

Interaction Types:
--> I prefer a classification = with Redirect, Decoupled and Embedded is. In the draft, we have one = redirect and 2 decouple interactions and nothing else.
[FI] = this should be handled as a specific discussion item. As a reminder, how = would you define embedded?

In = practice there's at least these modes:
- = redirect and redirect back
- = redirect to different browser or device
- = user code
- = CIBA
[FP] This classification is = limited.
  • Redirect: same device, same or different user agents = (browser, mobile app, desktop app, ...)
  • Decoupled: = different devices
  • Embedded : RC carries RO = authorization to AS


Resource Access Request vs. = Resource Request
--> Both are mixed up. No = clarification of the context of each section.
[FI] = could you clarify what you'd expect.  Btw on this topic, there's a = more general discussion on whether we should make a distinction or = not. 
=E2=80=8B[FP]: = Here:
  • Resource Access Request: = Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request = the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This = is central to GNAP and not represented enough  in the = document.
[FI] = right. This should be a specific discussion item. 

Requesting "User" Information
we identify two types of users: RQ = and RO. It will be better not to refer to a user in this draft, but = either to a RQ or an RO.
[FI] = yes that would avoid potential misunderstandings. Although in the end, = people will translate RQ into user or end-user most of the time. Cf = in definition, currently we have Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we = will have to describe the protocol flow and the nature and behavior of = involved Roles (Parties), Elements, Requests.
[FI] = yes  

[FP] Will these and into tickets?

Best regards.
/Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

--
TXAuth mailing list
TXAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/txauth


--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_BAAD65CC-57A2-4826-B3B7-A06F2A00E596-- From nobody Thu Feb 4 13:10:26 2021 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 EC4EA3A1835 for ; Thu, 4 Feb 2021 13:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 NL5vmLqWDMpl for ; Thu, 4 Feb 2021 13:10:19 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 AEF7D3A1838 for ; Thu, 4 Feb 2021 13:10:19 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id u66so3290795oig.9 for ; Thu, 04 Feb 2021 13:10:19 -0800 (PST) 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=XCmX17PqyyMAc5g96MCRZiqnqzjyOb0HVnLWVCfc/d4=; b=i++i/XKYdLqbEWAwlO1Y0ilUAXmgdszrewSCXHPn/LD+22Qs590xAM+sCqI3qU4v8i Yr/ZScVcODLj5ze3V0TaMOCob9FHRXUJeBpsYkV6qH6rNZUbUMgrQ9PZQR7ZUj1mWWMZ 0Ea3liDovNXkZlBJbsOZRnflH8XQ+9W+44xylhs8no1GzacWepaFSjANWh75Zl7iZcvT PTMK0evqrsHL1cVC4icCKnNvmJbbuyjkoHyjTO3j9POqtH1zMqdHI6axRQwdD53JfACr pP1zapOTdbX8rMp8kigqUd+KQqju+LnG6D3sXjbfWOMVfVL+AV1mRX8EPe20jjgQc+Cq 60rA== 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=XCmX17PqyyMAc5g96MCRZiqnqzjyOb0HVnLWVCfc/d4=; b=tRuo4zsxC1oZI3AkDJEGbiZdboRPe16ZWcoqQL3QLE8p7pea3G8DFluXXSZ2Riu4mU J4u2D356nZkeBXzK7ZFDAJArbwie8QguLKCubhNxdRLdOlsLNf6IFW1huyvZSZ5mNCGY W2e7j4bmJUfK3308LG1T6Cu8Wq+YcfNwArCvmzLmsgbxXnhO69MC9fe5sYjTckBTL4lW SLDsisuqM2AUd0fUSwCi9t2JkVk7MwxTo/PRNkCfCxz/6wkK2u8qe05iWKar6HuIb314 JzqHmIxegkP/yOaHTEsHkSBRIaWSbfCYy2TGF2ubPMzd+24ZDvneu/63yRTHSOZCtE6T PD2w== X-Gm-Message-State: AOAM530DkU8awyT5/1gTKoVsL6mIhcHLeE436Fj0Uu3py/wm4FjoNCZW 8gcxk1GoWFf3umzCNMODfXnl4vs9fqf+P3lg5n/nylt3fRc= X-Google-Smtp-Source: ABdhPJwNcwowRfAPSrQN7ajWLv7oUUNR/l7m3kEhpZT1eLe07Pca2F08hcDGTs8nnzphJp3FEUTcdAkcxgGjmBflZX8= X-Received: by 2002:aca:c514:: with SMTP id v20mr974029oif.131.1612473018562; Thu, 04 Feb 2021 13:10:18 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> <77D1AE7B-076F-4095-8FAA-7C35D74614BD@mit.edu> In-Reply-To: From: Tom Jones Date: Thu, 4 Feb 2021 13:10:05 -0800 Message-ID: To: Justin Richer Cc: Fabien Imbault , txauth gnap Content-Type: multipart/alternative; boundary="0000000000007b3b9305ba89213f" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 21:10:24 -0000 --0000000000007b3b9305ba89213f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable discovery is the prime problem. What causes the wallet/AS to wake up and pay attention. How does the RP know what to ask for without violating user privacy rights? CHAPI would be ok i guess, but that requires cred man to be fixed. Not sure if it fixes discovery or privacy even then. Be the change you want to see in the world ..tom On Thu, Feb 4, 2021 at 12:45 PM Justin Richer wrote: > Tom, what additional functionality do you see that a browser would need t= o > support in order for GNAP to be adopted? For the elements of the core > protocol today, nothing is needed to change within the browsers =E2=80=94 > everything is built on existing functions. GNAP uses browsers as a tool, > and I would argue depends on them even less so than OAuth 2 does. > Extensions could use browser functionality, like using CHAPI to pass > interaction elements, but the core protocol functions on vanilla browsers > today. > > =E2=80=94 Justin > > On Feb 4, 2021, at 3:20 PM, Tom Jones > wrote: > > i assumed that the wallet (aka AS) needed to be a native app, not a PWA > (which can come from a traditional web server). > There are folks, lke Kim C, who are working on a PWA, but i agree the > blocks there seem to be large. > THe blocks on a native app are simple, easy to describe, and easy to ask > the browser guys to fix. Not sure if they care tho. > I have trouble seeing a path to GNAP adoption for retail customers w/o > some browser support. > That's why i am mostly silent here. > > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault > wrote: > >> Fair enough. But loopback limits a lot what you can do... Just for debug >> it's a pain. >> But as soon as you try more, it's a bit crazy. Fun to test ipv6 (luckily >> supported by my ISP) and ddns. But it feels really hacky. >> Also deployment is a pain, compared to a traditional webserver. >> >> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones a >> =C3=A9crit : >> >>> doesn't work very well on windows uwp. works fine on smartphones >>> Be the change you want to see in the world ..tom >>> >>> >>> On Thu, Feb 4, 2021 at 11:18 AM Justin Richer wrote: >>> >>>> OK, thanks =E2=80=94 in that case, there are no changes at all to GNAP= , which >>>> is already HTTP driven. The harder parts tend to be where you can=E2= =80=99t (or >>>> don=E2=80=99t want to) use something like that. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Feb 4, 2021, at 2:16 PM, Tom Jones >>>> wrote: >>>> >>>> yes, loopback >>>> >>>> Be the change you want to see in the world ..tom >>>> >>>> >>>> On Thu, Feb 4, 2021 at 11:01 AM Justin Richer wrote: >>>> >>>>> Tom, can you expand on how exactly the back-channel communication >>>>> works between on-device components? Do you use HTTP locally? >>>>> >>>>> Thanks, >>>>> =E2=80=94 Justin >>>>> >>>>> On Feb 4, 2021, at 1:03 PM, Tom Jones >>>>> wrote: >>>>> >>>>> Justin's analysis of use of the front channel is misleading. >>>>> It could equally be argued that what i have done is installed an AS o= n >>>>> the phone and the communications with it & the PR is back channel. >>>>> Basically the point is that the old OIDC paradigms are no longer vali= d. >>>>> Be the change you want to see in the world ..tom >>>>> >>>>> >>>>> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Yes, issue (#168) message based interaction / DIDComm is a tentative >>>>>> alternative mecanism for the interaction part. Not sure how that wou= ld work >>>>>> in details though, prototyping will probably help here. >>>>>> Token delivery through continuation seems fine to me. The client wil= l >>>>>> probably have to wait for the next polling before it receives a toke= n >>>>>> issued as the result of an asynchronous interaction, but that's not = a big >>>>>> issue. >>>>>> >>>>>> But the AS on the phone seems like a harder nut to crack, at least a= t >>>>>> first sight. I think that would be awesome, but it gives me headache= s, so I >>>>>> think I'll work on easier stuff right now ;-) >>>>>> >>>>>> Fabien >>>>>> >>>>>> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer wrote= : >>>>>> >>>>>>> One of the biggest drawbacks of the current app-centric approaches >>>>>>> in OIDC (self-issued OP, or SIOP) is that they depend on using the = front >>>>>>> channel and browser redirects to pass everything, which is somethin= g that >>>>>>> GNAP is deliberately getting away from by starting in the back chan= nel. >>>>>>> >>>>>>> That said, once a request is kicked off in GNAP, the interaction an= d >>>>>>> fulfillment can happen through any number of means. Part of the wor= k that=E2=80=99s >>>>>>> being done with the =E2=80=9Cinteraction=E2=80=9D section is going = to help facilitate this, >>>>>>> and I think that there are some other potential branches here. >>>>>>> >>>>>>> Token delivery is where things get extra weird though =E2=80=94 we = are >>>>>>> explicitly not delivering tokens in the front channel in the core o= f GNAP, >>>>>>> we=E2=80=99re using the response from the continuation API. One ide= a (that isn=E2=80=99t >>>>>>> particularly well thought out and hasn=E2=80=99t been implemented a= t all) is to >>>>>>> have an extension declare an alternative response from the =E2=80= =9Ccontinue=E2=80=9D >>>>>>> section that=E2=80=99s defined today, which points to the GNPA cont= inuation API. If >>>>>>> an extension defines some alternative way to deliver tokens, that c= ould >>>>>>> live alongside a continuation API and the client could indicate sup= port for >>>>>>> it in its initial request. >>>>>>> >>>>>>> In any event, alternative interaction and delivery methods are >>>>>>> important, and even if we aren=E2=80=99t going to support every las= t one of them >>>>>>> directly, the protocol design should at least be aware of them. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault >>>>>>> wrote: >>>>>>> >>>>>>> Hi Tom, >>>>>>> >>>>>>> Sure, any experience on that would be greatly appreciated, we're >>>>>>> calling for help here (the point being that I suspect what they're = doing is >>>>>>> not trivial). >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones < >>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>> >>>>>>>> I've had such an app working for over a year. There are issues >>>>>>>> which are being addressed by the browser Interaction team of oidc. >>>>>>>> >>>>>>>> thx ..Tom (mobile) >>>>>>>> >>>>>>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi Francis, >>>>>>>>> >>>>>>>>> I've tried a few things with regards to using the AS on a phone, >>>>>>>>> but it's really quite complex. >>>>>>>>> >>>>>>>>> Making that run on a phone comes with quite a bit of trouble. The >>>>>>>>> most difficult part if that we'd need to use a secure element, bu= t just >>>>>>>>> installing and hosting a http server securely is not a standard s= etup at >>>>>>>>> all. I suggest interested people step in to work on this, as we a= lready >>>>>>>>> have a lot of work for the (more usual) server case and already h= andle a >>>>>>>>> privacy preserving scheme. >>>>>>>>> >>>>>>>>> Please let us know what you think. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Francis, >>>>>>>>>> >>>>>>>>>> I've thought a bit more to what you said. I think I'll give it a >>>>>>>>>> try as a separate experiment (in code, not in theory). Not that = I would >>>>>>>>>> expect it to be included in GNAP, but I kind of like the idea :-= ) >>>>>>>>>> >>>>>>>>>> The direct impact for GNAP would be to think about multiple ASs. >>>>>>>>>> >>>>>>>>>> Will let you know. >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha >>>>>>>>>> a =C3=A9crit : >>>>>>>>>> >>>>>>>>>>> It would be nice if the protocol was designed at many layers of >>>>>>>>>>> abstraction. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - The first layer shall design abstract protocol flows, >>>>>>>>>>> without specification of the mode and mechanism of interacti= on. >>>>>>>>>>> - The second layer can instantiate the first layer for >>>>>>>>>>> dedicated interaction. Here we can talk http, we can define = interactions >>>>>>>>>>> that presume server based token generation, we can define in= teraction that >>>>>>>>>>> run on user device based token generation. >>>>>>>>>>> >>>>>>>>>>> This is also the fundament of the structure I proposed for the >>>>>>>>>>> spec ( >>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). >>>>>>>>>>> >>>>>>>>>>> /Francis >>>>>>>>>>> >>>>>>>>>>> ------------------------------ >>>>>>>>>>> *From:* Fabien Imbault >>>>>>>>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>>>>>>>>> *To:* Francis Pouatcha >>>>>>>>>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>>>>>>>>> dick.hardt@gmail.com>; Tom Jones = ; >>>>>>>>>>> Denis ; Justin Richer >>>>>>>>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-0= 0 >>>>>>>>>>> >>>>>>>>>>> Would make sense, but not so easy as we rely heavily on HTTP. >>>>>>>>>>> Hence the discussion about deep links and so on. >>>>>>>>>>> >>>>>>>>>>> An alternative might be provided by wasm/wasi (running a local >>>>>>>>>>> sandbox on your phone, for your own AS), but it's really early = stage. This >>>>>>>>>>> also poses another question that Denis has put forward, i.e. ho= w do we >>>>>>>>>>> handle the multiple AS scenario (likely to occur then). >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha < >>>>>>>>>>> fpo@adorsys.de> wrote: >>>>>>>>>>> >>>>>>>>>>> We are drifting away from the original problem space. >>>>>>>>>>> >>>>>>>>>>> - My original mention was about the "POST" request, that >>>>>>>>>>> subsumes that the "AS" is a "Server". Designing a new protoc= ol, we cannot >>>>>>>>>>> afford this limitation. >>>>>>>>>>> - I just mentioned SIOP to show a known and closed example? >>>>>>>>>>> Let us not focus on the device local discovery scheme (like = openid:) for >>>>>>>>>>> now. >>>>>>>>>>> - As capability of holding private keys on user device >>>>>>>>>>> evolves, server-based issuing of token will be fading out gi= ving way to >>>>>>>>>>> device local generation of token. >>>>>>>>>>> >>>>>>>>>>> While designing GNAP, let us assume the AS-Role can be exercise= d >>>>>>>>>>> on a user device and design the protocol to honor that. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> /Francis >>>>>>>>>>> ------------------------------ >>>>>>>>>>> *From:* TXAuth on behalf of Dick >>>>>>>>>>> Hardt >>>>>>>>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>>>>>>>>> *To:* Tom Jones >>>>>>>>>>> *Cc:* Fabien Imbault ; Denis < >>>>>>>>>>> denis.ietf@free.fr>; GNAP Mailing List ; >>>>>>>>>>> Justin Richer >>>>>>>>>>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-0= 0 >>>>>>>>>>> >>>>>>>>>>> Got it. >>>>>>>>>>> >>>>>>>>>>> So web apps invoke a openid: deep link and hope there is an app >>>>>>>>>>> to handle the openid: scheme? ... and that it is the user's wal= let rather >>>>>>>>>>> than some malware that has registered openid: on the mobile dev= ice? >>>>>>>>>>> >>>>>>>>>>> A native app can attempt to open a deep link associated with an >>>>>>>>>>> app, and will fail if the app is not there. If the app is there= , it will be >>>>>>>>>>> opened, so this can't be used to silently test if an app is pre= sent, but it >>>>>>>>>>> does allow a native app to provide an alternative experience if= an app is >>>>>>>>>>> not present. I don't think this works with custom schemes ... a= nd I don't >>>>>>>>>>> know how it could work from a web app on the phone with the cur= rent Safari >>>>>>>>>>> APIs. >>>>>>>>>>> >>>>>>>>>>> Apple warns against using custom schemes [1] ... but perhaps >>>>>>>>>>> they can be convinced to make openid: a managed scheme similar = to mailto:, >>>>>>>>>>> tel:, sms:, facetime: ? >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> https://developer.apple.com/documentation/xcode/allowing_apps_a= nd_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_a= pp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> =E1=90=A7 >>>>>>>>>>> >>>>>>>>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> You are - that is not standard which is opeind:// >>>>>>>>>>> This is the one step that still needs to be optimized for SIOP >>>>>>>>>>> to have good UX. >>>>>>>>>>> Peace ..tom >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Tom >>>>>>>>>>> >>>>>>>>>>> I watched your video (I watched at 2X speed) >>>>>>>>>>> >>>>>>>>>>> Looks like the employment website app that is using >>>>>>>>>>> localhost:8765 to communicate with the wallet. Am I correct? >>>>>>>>>>> >>>>>>>>>>> /Dick >>>>>>>>>>> =E1=90=A7 >>>>>>>>>>> >>>>>>>>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones < >>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Well, here's a demo. Note that in this case the AS is not onlin= e >>>>>>>>>>> all of the time, so it is really implicit flow and the OIDC id-= token comes >>>>>>>>>>> from the siop device directly. >>>>>>>>>>> (whether this is front-channel or back channel is no longer an >>>>>>>>>>> interesting question.) >>>>>>>>>>> Now if an always-on AS is required, that is possible, but >>>>>>>>>>> probably beyond the scope of this effort and would require some= thing like >>>>>>>>>>> an agent-in-the-sky (with diamonds). >>>>>>>>>>> here is the link to the 9 min video https://youtu.be >>>>>>>>>>> /Tq4hw7X5SW0 >>>>>>>>>>> >>>>>>>>>>> Peace ..tom >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Ultimately, in most situations like these in the real world, th= e >>>>>>>>>>> hurdle isn=E2=80=99t technical compatibility so much as it is t= rust compatibility. >>>>>>>>>>> The RP (client) needs to have some incentive to trust the asser= tions and >>>>>>>>>>> identity information that=E2=80=99s coming from the AS. The sam= e is true for an RS >>>>>>>>>>> trusting tokens from the AS. The hard question is less =E2=80= =9Chow=E2=80=9D to do that >>>>>>>>>>> (which SSI answers), but more =E2=80=9Cwhy=E2=80=9D to do that = (which SSI doesn=E2=80=99t answer >>>>>>>>>>> very well, because it=E2=80=99s a hard question). >>>>>>>>>>> >>>>>>>>>>> Still: it=E2=80=99s definitely a question about how to support = this =E2=80=9CAS >>>>>>>>>>> on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by >>>>>>>>>>> allowing the bootstrap of the process from a starting call: the= interaction >>>>>>>>>>> and continuation URIs handed back by the AS don=E2=80=99t need = to be the same URIs >>>>>>>>>>> that the client starts with, so just like SIOP the process can = start in >>>>>>>>>>> HTTP and potentially move to other communication channels. A ma= jor >>>>>>>>>>> difference is that we aren=E2=80=99t dependent on the assumptio= n that the user will >>>>>>>>>>> always be in a browser at some stage, and so the whole raft of >>>>>>>>>>> front-channel messages that SIOP relies on doesn=E2=80=99t fly.= That said, we=E2=80=99ve >>>>>>>>>>> got an opportunity to more explicitly open up alternative commu= nication >>>>>>>>>>> channels here, and that=E2=80=99s something I=E2=80=99d like to= see engineered, even if >>>>>>>>>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete p= roposal as to how that would >>>>>>>>>>> work over specific protocols, starting with what we=E2=80=99ve = got today. >>>>>>>>>>> >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>> >>>>>>>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Denis, hi Francis, >>>>>>>>>>> >>>>>>>>>>> At some point integration with SSI (on the authentication side) >>>>>>>>>>> will probably occur, including amongst other possibilities SIOP= (since they >>>>>>>>>>> work with OpenID a part of the work will probably be made easie= r). >>>>>>>>>>> >>>>>>>>>>> That being said, Denis is right. It's not an AS. Technically >>>>>>>>>>> it's entirely possible to rely on a decentralized wallet (for i= nstance on >>>>>>>>>>> your phone) and a centralized AS. I know of a few studies on ho= w to >>>>>>>>>>> decentralize the AS itself (for instance >>>>>>>>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-= 02 >>>>>>>>>>> ). >>>>>>>>>>> Maybe it exists, but I'm still looking for real scenarios (or >>>>>>>>>>> even architectures) where an AS is deployed directly on a phone= , and under >>>>>>>>>>> the sole authority of the RO, while being compatible with the r= est of the >>>>>>>>>>> world. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hello Francis, >>>>>>>>>>> >>>>>>>>>>> See two comments in line. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> B) Current Document >>>>>>>>>>> >>>>>>>>>>> Roles description shall not hold any assumption on the physical >>>>>>>>>>> structure of the party fulfilling the roles. >>>>>>>>>>> [FI] not sure what you mean >>>>>>>>>>> >>>>>>>>>>> [FP] for example, we assume the AS is a server! In most SSI >>>>>>>>>>> based use cases, the AS will be running on the user device. See= SIOP ( >>>>>>>>>>> https://identity.foundation/did-siop/). >>>>>>>>>>> >>>>>>>>>>> I browsed through the two drafts, i.e. : >>>>>>>>>>> >>>>>>>>>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, >>>>>>>>>>> data model, and representations W3C Working Draft 08 Novembe= r 2020 >>>>>>>>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF >>>>>>>>>>> Working Group Draft >>>>>>>>>>> >>>>>>>>>>> At no place within these two documents, it is possible to >>>>>>>>>>> imagine that "the AS will be running on the user device". >>>>>>>>>>> >>>>>>>>>>> From section 3 of the DIF Working Group Draft: >>>>>>>>>>> >>>>>>>>>>> "Unlike the OIDC Authorization Code Flow as per >>>>>>>>>>> [OIDC.Core], the SIOP will not return an access token to the RP= ". >>>>>>>>>>> >>>>>>>>>>> An Identity Wallet is not an AS. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Roles: >>>>>>>>>>> -> grant endpoint of the AS: Why is this a post request? This >>>>>>>>>>> eliminates the chance of having user device hosted AS (no serve= r). >>>>>>>>>>> [FI] what would you propose instead? >>>>>>>>>>> Would also be interested to understand better the deployment >>>>>>>>>>> model when there is no server. That's something that was discus= sed several >>>>>>>>>>> times but I'm still missing the underlying architecture and use= case. >>>>>>>>>>> >>>>>>>>>>> [FP] See above (SIOP). There will be a lot of identity wallets >>>>>>>>>>> operated on end user device. >>>>>>>>>>> >>>>>>>>>>> See the above comment. Please, do not confuse an Identity Walle= t >>>>>>>>>>> with an Authentication Server (AS). >>>>>>>>>>> >>>>>>>>>>> Denis >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it >>>>>>>>>>> authorize the request or the access to a resource? >>>>>>>>>>> [FI] yes, we should make the wording clearer >>>>>>>>>>> >>>>>>>>>>> Missing Section Interactions: >>>>>>>>>>> --> This section shall introduce the notion of interaction >>>>>>>>>>> before we start listing interaction types. >>>>>>>>>>> [FI] yes >>>>>>>>>>> >>>>>>>>>>> Interaction Types: >>>>>>>>>>> --> I prefer a classification with Redirect, Decoupled and >>>>>>>>>>> Embedded is. In the draft, we have one redirect and 2 decouple = interactions >>>>>>>>>>> and nothing else. >>>>>>>>>>> [FI] this should be handled as a specific discussion item. As a >>>>>>>>>>> reminder, how would you define embedded? >>>>>>>>>>> >>>>>>>>>>> In practice there's at least these modes: >>>>>>>>>>> - redirect and redirect back >>>>>>>>>>> - redirect to different browser or device >>>>>>>>>>> - user code >>>>>>>>>>> - CIBA >>>>>>>>>>> >>>>>>>>>>> [FP] This classification is limited. >>>>>>>>>>> >>>>>>>>>>> - Redirect: same device, same or different user agents >>>>>>>>>>> (browser, mobile app, desktop app, ...) >>>>>>>>>>> - Decoupled: different devices >>>>>>>>>>> - Embedded : RC carries RO authorization to AS >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Resource Access Request vs. Resource Request >>>>>>>>>>> --> Both are mixed up. No clarification of the context of each >>>>>>>>>>> section. >>>>>>>>>>> [FI] could you clarify what you'd expect. Btw on this topic, >>>>>>>>>>> there's a more general discussion on whether we should make a d= istinction >>>>>>>>>>> or not. >>>>>>>>>>> >>>>>>>>>>> =E2=80=8B[FP]: Here: >>>>>>>>>>> >>>>>>>>>>> - Resource Access Request: Requesting Access to a resource. >>>>>>>>>>> Response is an access token (or any type of grant) >>>>>>>>>>> - Resource Request: Request the resource. Response is the >>>>>>>>>>> resource (or a corresponding execution) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Token Content Negotiation >>>>>>>>>>> --> Not expressed as such. This is central to GNAP and not >>>>>>>>>>> represented enough in the document. >>>>>>>>>>> [FI] right. This should be a specific discussion item. >>>>>>>>>>> >>>>>>>>>>> Requesting "User" Information >>>>>>>>>>> we identify two types of users: RQ and RO. It will be better no= t >>>>>>>>>>> to refer to a user in this draft, but either to a RQ or an RO. >>>>>>>>>>> [FI] yes that would avoid potential misunderstandings. Although >>>>>>>>>>> in the end, people will translate RQ into user or end-user most= of the >>>>>>>>>>> time. Cf in definition, currently we have Requesting Party (RQ, >>>>>>>>>>> aka "user") >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Interaction Again >>>>>>>>>>> -> For each interaction type, we will have to describe the >>>>>>>>>>> protocol flow and the nature and behavior of involved Roles (Pa= rties), >>>>>>>>>>> Elements, Requests. >>>>>>>>>>> [FI] yes >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [FP] Will these and into tickets? >>>>>>>>>>> >>>>>>>>>>> Best regards. >>>>>>>>>>> /Francis >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> TXAuth mailing list >>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> TXAuth mailing list >>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> TXAuth mailing list >>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> TXAuth mailing list >>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>> >>>>>>>>>>> >>>>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> >>>>> >>>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> > --0000000000007b3b9305ba89213f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
discovery is the prime problem.=C2=A0 What causes the wall= et/AS to wake up and pay attention. How does the RP know what to ask for wi= thout violating user privacy rights?

CHAPI would be ok i= guess, but that requires cred man to be fixed. Not sure if it fixes discov= ery or privacy even then.

Be = the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 12:45 PM Justin Richer <jricher@mit.edu> wrote:
Tom, what additional functionality do you see that a browser woul= d need to support in order for GNAP to be adopted? For the elements of the = core protocol today, nothing is needed to change within the browsers =E2=80= =94 everything is built on existing functions. GNAP uses browsers as a tool= , and I would argue depends on them even less so than OAuth 2 does. Extensi= ons could use browser functionality, like using CHAPI to pass interaction e= lements, but the core protocol functions on vanilla browsers today.
=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 3:20 PM, Tom Jones <thomasclinganjones@gmail.com> wr= ote:

i assumed that the wallet (aka AS) need= ed to be a native app, not a PWA (which can come from a traditional web ser= ver).
There are folks, lke Kim C, who are working on a PWA, but i agree= the blocks there seem to be large.
THe blocks on a native app ar= e simple, easy to describe, and easy to ask the browser guys to fix. Not su= re if they care tho.
I have trouble seeing a path to GNAP adoptio= n for retail customers w/o some browser support.
That's why i= am mostly=C2=A0silent here.

Be the= change you want to see in the world ..tom

On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault <fabien.imbault@gmail.com&= gt; wrote:
Fair enough. But loopback limits a lot what you can do... Just= for debug it's a pain.=C2=A0
But as soon as you try m= ore, it's a bit crazy. Fun to test ipv6 (luckily supported by my ISP) a= nd ddns. But it feels really hacky.=C2=A0
Also deplo= yment is a pain, compared to a traditional webserver.=C2=A0

=
Le jeu. 4 = f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit=C2=A0:
doesn= 't work very well on windows uwp. works fine on smartphones
Be the change you want to see in the world ..= tom


<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 4, 2021 at 11:18 AM Justin= Richer <jricher@mit.edu>= ; wrote:
OK= , thanks =E2=80=94 in that case, there are no changes at all to GNAP, which= is already HTTP driven. The harder parts tend to be where you can=E2=80=99= t (or don=E2=80=99t want to) use something like that.

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

On Feb 4,= 2021, at 2:16 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

yes, loopback

Be the = change you want to see in the world ..tom

On Thu, Feb 4, 2021 at 11:01 AM Justin Richer <jricher@mit.edu> wrote:
Tom, can you expand on how exact= ly the back-channel =C2=A0communication works between on-device components?= Do you use HTTP locally?

Thanks,
=C2=A0=E2=80= =94 Justin

On Feb 4, 2021, at 1:= 03 PM, Tom Jones <= thomasclinganjones@gmail.com> wrote:

= Justin's analysis of use of the front channel is misleading.
It cou= ld equally be argued that what i have done is installed an AS on the phone = and the communications with it & the PR is back channel.
Basi= cally the point is that the old OIDC paradigms are no longer valid.
Be the change you want to see in the world ..t= om


On Thu, Feb 4, 2021 at 7:47 AM Fabien I= mbault <fabien.imbault= @gmail.com> wrote:
Yes, issue (#168)=C2=A0message based interactio= n / DIDComm is a tentative alternative mecanism for the interaction part. N= ot sure how that would work in details=C2=A0though, prototyping will probab= ly help here.
Token delivery=C2=A0through continuation seems fine to me= . The client will probably have to wait for the next polling before it rece= ives a token issued as the result of an asynchronous interaction, but that&= #39;s not a big issue.

But the AS on the phone see= ms like a harder nut to crack, at least at first sight. I think that would = be awesome, but it gives me headaches, so I think I'll work on easier s= tuff right now ;-)

Fabien=C2=A0=C2=A0

On = Thu, Feb 4, 2021 at 4:30 PM Justin Richer <jricher@mit.edu> wrote:
One of the biggest drawbacks of the current= app-centric approaches in OIDC (self-issued OP, or SIOP) is that they depe= nd on using the front channel and browser redirects to pass everything, whi= ch is something that GNAP is deliberately getting away from by starting in = the back channel.

That said, once a request is kicked of= f in GNAP, the interaction and fulfillment can happen through any number of= means. Part of the work that=E2=80=99s being done with the =E2=80=9Cintera= ction=E2=80=9D section is going to help facilitate this, and I think that t= here are some other potential branches here.

Token= delivery is where things get extra weird though =E2=80=94 we are explicitl= y not delivering tokens in the front channel in the core of GNAP, we=E2=80= =99re using the response from the continuation API. One idea (that isn=E2= =80=99t particularly well thought out and hasn=E2=80=99t been implemented a= t all) is to have an extension declare an alternative response from the =E2= =80=9Ccontinue=E2=80=9D section that=E2=80=99s defined today, which points = to the GNPA continuation API. If an extension defines some alternative way = to deliver tokens, that could live alongside a continuation API and the cli= ent could indicate support for it in its initial request.

In any event, alternative interaction and delivery methods are impo= rtant, and even if we aren=E2=80=99t going to support every last one of the= m directly, the protocol design should at least be aware of them.

=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 8:35 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
<= br>
Hi Tom,=C2=A0

Sure, any experie= nce on that would be greatly appreciated, we're calling for help here (= the point being that I suspect what they're doing is not trivial).

Fabien

On Thu, Feb 4, 2021 at 2:21 PM Tom Jones &= lt;thomasclinganjones= @gmail.com> wrote:
I've had such an app working for over a ye= ar. There are issues which are being addressed by the browser Interaction t= eam of oidc.

thx ..Tom (mobile)

On Thu, Feb 4, 2021, 3:12 = AM Fabien Imbault <fab= ien.imbault@gmail.com> wrote:
Hi Francis,=C2=A0

= I've tried a few things with regards to using the AS on a phone, but it= 's really quite=C2=A0complex.=C2=A0

Making tha= t run on a phone comes with quite a bit of trouble. The most difficult part= if that we'd need to use a secure element, but just installing and hos= ting a http server securely is not a standard setup at all. I suggest inter= ested people step in to work on this, as we already have a lot of work for = the (more usual) server case and already handle a privacy preserving scheme= .=C2=A0

Please let us know what you think.

Cheers,
Fabien=C2=A0

On Tue, Nov 24, 2020= at 5:55 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,=

I've thought a bit more t= o what you said. I think I'll give it a try as a separate experiment (i= n code, not in theory). Not that I would expect it to be included in GNAP, = but I kind of like the idea :-)

The direct impact for GNAP would be to think about multiple ASs.= =C2=A0

Will let you know= .=C2=A0

Fabien=C2=A0

= Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha <fpo@adorsys.de> a =C3=A9crit=C2=A0:<= br>
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"gmail-m_7901394266816005280gmail-m_-6718184999452512077m_-3004232231493= 229381m_-8862550958674531306m_4552653984562635461m_387929924441527190m_6662= 104191003806385gmail-m_-542839070341023388gmail-m_-6176056956474019294gmail= -m_-3037161202240578685gmail-m_-7520389457378808664gmail-m_-334202478233056= 9254m_8014700032835912204gmail-m_142651873244800559m_8348797445460806175LPl= nk338391" rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer nor= eferrer noreferrer" target=3D"_blank">https://github.com/ietf-wg-gnap/gnap-= core-protocol/issues/30).

/Francis

From: Fabien Imbault <fabien.imbault@gmail.com&g= t;
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: t= xauth@ietf.org <txauth@ietf.org>; Dick Hardt <dick.hardt@gmail.com>; = Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@adorsys.de> wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-bo= unces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@fr= ee.fr>; GNAP Mailing List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclin= ganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.c= om> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomascling= anjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.be<= /span>/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu= > wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com= > wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https:/= /tools.ietf.org/html/draft-hardjono-oauth-decentralized-02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr>= ; wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= =E2=80=8B= [FP]: Here:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


--
TXAuth mailing list
TXAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/txauth

--0000000000007b3b9305ba89213f-- From nobody Fri Feb 5 03:19:48 2021 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 421663A0C7C for ; Fri, 5 Feb 2021 03:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 oNtnLsffEXNE for ; Fri, 5 Feb 2021 03:19:43 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 F37AB3A0C7A for ; Fri, 5 Feb 2021 03:19:42 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id s24so6652658iob.6 for ; Fri, 05 Feb 2021 03:19:42 -0800 (PST) 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=VKcpYe2izGNMR0C/bRtAhJDeNHMXbFtp+qOT/Xm2dz0=; b=rWbXTLZ2sLVexfv6hqCczgmrp/d2WzqBmIU6/bexPvp/DNz/glbkrK1l+9GaQgt+H+ sNmrJ/kUbJ9dq2oQdBCoFQNzYjesxNJiQsWsu+xM5HDXaJSgmiLnfBX9oTKsFqyqykdV OF7Bnd1KyHUOxH5zIPCPgOOKcipjZvX+PKv4Vlg+ild5zlMvy7qH8nQbaTCa+s4QpOx0 zMTbO1ip+wo9snlvZ7LQ7Z5tDdcLHbk5RDMXUuAioj9jpH/5Z8zA8pxlyakLelfffYpU P+9NN5byxz2w7R1iOYVZfbvJLILD9WSWjq/gZJRcfN58/Gw3nYAqo586KIRef8MFjB11 iqvw== 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=VKcpYe2izGNMR0C/bRtAhJDeNHMXbFtp+qOT/Xm2dz0=; b=BXDDn7BV7alcgldzmFvbnvwv7EfmzEy1pF8FXRTm3X9TtsWBTi/+zuZNy31y8a4ujs JDHLelezNkPsZ6/K+fyTeSAT/a3DeO+uk/5qjC8RTZ9H/R61O/eCJQAkZiLqlH66rDMg rLzQUwRgP8XnemB52zT1sjJdp7zghgKTXdH414YHat2x1Ine94di5sr5lnAf5xhttc/K mdHTWm4tFE9zq9KOQkWoNwByrg4pz9XPtWaC8fvOvs7pPY2AQQ7NGm01mZT/NwFbDJ3U V5p9YhYzFGVgnfzNeDdvhftbsoBV0wArNuu1iNTwC1VTpgT+ER9XyMPk2CJMYQ1LpTpK YQ+g== X-Gm-Message-State: AOAM532bDhjHiH0y/wAWv7jaHk8W6t/DbThqZWHY5VpNILIL87sy+K1I MY6sZ/O7lVMoum4FqVKVu5XqNrRegAI2ogoeiuc= X-Google-Smtp-Source: ABdhPJxiIiFnqE/jIk4kW9Sb64BdBxe8pMk+QGx3ggsqJ61vrwHACoZqHp7+UbEUZxnSD2ofc8yoJ4TohFxbTopN/3Q= X-Received: by 2002:a6b:510d:: with SMTP id f13mr3386829iob.141.1612523982133; Fri, 05 Feb 2021 03:19:42 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> <77D1AE7B-076F-4095-8FAA-7C35D74614BD@mit.edu> In-Reply-To: From: Fabien Imbault Date: Fri, 5 Feb 2021 12:19:27 +0100 Message-ID: To: Tom Jones Cc: Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="000000000000259e6305ba94ffdd" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 11:19:47 -0000 --000000000000259e6305ba94ffdd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tom, Thanks, your responses made it clearer for me what you expect from an AS deployed on a mobile. I think we're on the right path to meet the rest of your concerns. There are already a few items on these: - privacy preserving techniques have been discussed and are likely to be included (I think). It's been recognized as a core concern - not exactly sure the meaning you give to discovery here (it's already been used in the WG but with a different meaning I believe). The request or the continuation api provide entry points to pay attention to. Is that enough for your use case ? Do you need something else ? (like SSE?) Cheers Fabien Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom Jones a =C3=A9crit : > discovery is the prime problem. What causes the wallet/AS to wake up and > pay attention. How does the RP know what to ask for without violating use= r > privacy rights? > > CHAPI would be ok i guess, but that requires cred man to be fixed. Not > sure if it fixes discovery or privacy even then. > > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 12:45 PM Justin Richer wrote: > >> Tom, what additional functionality do you see that a browser would need >> to support in order for GNAP to be adopted? For the elements of the core >> protocol today, nothing is needed to change within the browsers =E2=80= =94 >> everything is built on existing functions. GNAP uses browsers as a tool, >> and I would argue depends on them even less so than OAuth 2 does. >> Extensions could use browser functionality, like using CHAPI to pass >> interaction elements, but the core protocol functions on vanilla browser= s >> today. >> >> =E2=80=94 Justin >> >> On Feb 4, 2021, at 3:20 PM, Tom Jones >> wrote: >> >> i assumed that the wallet (aka AS) needed to be a native app, not a PWA >> (which can come from a traditional web server). >> There are folks, lke Kim C, who are working on a PWA, but i agree the >> blocks there seem to be large. >> THe blocks on a native app are simple, easy to describe, and easy to ask >> the browser guys to fix. Not sure if they care tho. >> I have trouble seeing a path to GNAP adoption for retail customers w/o >> some browser support. >> That's why i am mostly silent here. >> >> Be the change you want to see in the world ..tom >> >> >> On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault >> wrote: >> >>> Fair enough. But loopback limits a lot what you can do... Just for debu= g >>> it's a pain. >>> But as soon as you try more, it's a bit crazy. Fun to test ipv6 (luckil= y >>> supported by my ISP) and ddns. But it feels really hacky. >>> Also deployment is a pain, compared to a traditional webserver. >>> >>> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones >>> a =C3=A9crit : >>> >>>> doesn't work very well on windows uwp. works fine on smartphones >>>> Be the change you want to see in the world ..tom >>>> >>>> >>>> On Thu, Feb 4, 2021 at 11:18 AM Justin Richer wrote: >>>> >>>>> OK, thanks =E2=80=94 in that case, there are no changes at all to GNA= P, which >>>>> is already HTTP driven. The harder parts tend to be where you can=E2= =80=99t (or >>>>> don=E2=80=99t want to) use something like that. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Feb 4, 2021, at 2:16 PM, Tom Jones >>>>> wrote: >>>>> >>>>> yes, loopback >>>>> >>>>> Be the change you want to see in the world ..tom >>>>> >>>>> >>>>> On Thu, Feb 4, 2021 at 11:01 AM Justin Richer wrote= : >>>>> >>>>>> Tom, can you expand on how exactly the back-channel communication >>>>>> works between on-device components? Do you use HTTP locally? >>>>>> >>>>>> Thanks, >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Feb 4, 2021, at 1:03 PM, Tom Jones >>>>>> wrote: >>>>>> >>>>>> Justin's analysis of use of the front channel is misleading. >>>>>> It could equally be argued that what i have done is installed an AS >>>>>> on the phone and the communications with it & the PR is back channel= . >>>>>> Basically the point is that the old OIDC paradigms are no longer >>>>>> valid. >>>>>> Be the change you want to see in the world ..tom >>>>>> >>>>>> >>>>>> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Yes, issue (#168) message based interaction / DIDComm is a tentativ= e >>>>>>> alternative mecanism for the interaction part. Not sure how that wo= uld work >>>>>>> in details though, prototyping will probably help here. >>>>>>> Token delivery through continuation seems fine to me. The client >>>>>>> will probably have to wait for the next polling before it receives = a token >>>>>>> issued as the result of an asynchronous interaction, but that's not= a big >>>>>>> issue. >>>>>>> >>>>>>> But the AS on the phone seems like a harder nut to crack, at least >>>>>>> at first sight. I think that would be awesome, but it gives me head= aches, >>>>>>> so I think I'll work on easier stuff right now ;-) >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> One of the biggest drawbacks of the current app-centric approaches >>>>>>>> in OIDC (self-issued OP, or SIOP) is that they depend on using the= front >>>>>>>> channel and browser redirects to pass everything, which is somethi= ng that >>>>>>>> GNAP is deliberately getting away from by starting in the back cha= nnel. >>>>>>>> >>>>>>>> That said, once a request is kicked off in GNAP, the interaction >>>>>>>> and fulfillment can happen through any number of means. Part of th= e work >>>>>>>> that=E2=80=99s being done with the =E2=80=9Cinteraction=E2=80=9D s= ection is going to help >>>>>>>> facilitate this, and I think that there are some other potential b= ranches >>>>>>>> here. >>>>>>>> >>>>>>>> Token delivery is where things get extra weird though =E2=80=94 we= are >>>>>>>> explicitly not delivering tokens in the front channel in the core = of GNAP, >>>>>>>> we=E2=80=99re using the response from the continuation API. One id= ea (that isn=E2=80=99t >>>>>>>> particularly well thought out and hasn=E2=80=99t been implemented = at all) is to >>>>>>>> have an extension declare an alternative response from the =E2=80= =9Ccontinue=E2=80=9D >>>>>>>> section that=E2=80=99s defined today, which points to the GNPA con= tinuation API. If >>>>>>>> an extension defines some alternative way to deliver tokens, that = could >>>>>>>> live alongside a continuation API and the client could indicate su= pport for >>>>>>>> it in its initial request. >>>>>>>> >>>>>>>> In any event, alternative interaction and delivery methods are >>>>>>>> important, and even if we aren=E2=80=99t going to support every la= st one of them >>>>>>>> directly, the protocol design should at least be aware of them. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>> Hi Tom, >>>>>>>> >>>>>>>> Sure, any experience on that would be greatly appreciated, we're >>>>>>>> calling for help here (the point being that I suspect what they're= doing is >>>>>>>> not trivial). >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones < >>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>> >>>>>>>>> I've had such an app working for over a year. There are issues >>>>>>>>> which are being addressed by the browser Interaction team of oidc= . >>>>>>>>> >>>>>>>>> thx ..Tom (mobile) >>>>>>>>> >>>>>>>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Francis, >>>>>>>>>> >>>>>>>>>> I've tried a few things with regards to using the AS on a phone, >>>>>>>>>> but it's really quite complex. >>>>>>>>>> >>>>>>>>>> Making that run on a phone comes with quite a bit of trouble. Th= e >>>>>>>>>> most difficult part if that we'd need to use a secure element, b= ut just >>>>>>>>>> installing and hosting a http server securely is not a standard = setup at >>>>>>>>>> all. I suggest interested people step in to work on this, as we = already >>>>>>>>>> have a lot of work for the (more usual) server case and already = handle a >>>>>>>>>> privacy preserving scheme. >>>>>>>>>> >>>>>>>>>> Please let us know what you think. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Francis, >>>>>>>>>>> >>>>>>>>>>> I've thought a bit more to what you said. I think I'll give it = a >>>>>>>>>>> try as a separate experiment (in code, not in theory). Not that= I would >>>>>>>>>>> expect it to be included in GNAP, but I kind of like the idea := -) >>>>>>>>>>> >>>>>>>>>>> The direct impact for GNAP would be to think about multiple ASs= . >>>>>>>>>>> >>>>>>>>>>> Will let you know. >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha >>>>>>>>>>> a =C3=A9crit : >>>>>>>>>>> >>>>>>>>>>>> It would be nice if the protocol was designed at many layers o= f >>>>>>>>>>>> abstraction. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - The first layer shall design abstract protocol flows, >>>>>>>>>>>> without specification of the mode and mechanism of interact= ion. >>>>>>>>>>>> - The second layer can instantiate the first layer for >>>>>>>>>>>> dedicated interaction. Here we can talk http, we can define= interactions >>>>>>>>>>>> that presume server based token generation, we can define i= nteraction that >>>>>>>>>>>> run on user device based token generation. >>>>>>>>>>>> >>>>>>>>>>>> This is also the fundament of the structure I proposed for the >>>>>>>>>>>> spec ( >>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). >>>>>>>>>>>> >>>>>>>>>>>> /Francis >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------ >>>>>>>>>>>> *From:* Fabien Imbault >>>>>>>>>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>>>>>>>>>> *To:* Francis Pouatcha >>>>>>>>>>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>>>>>>>>>> dick.hardt@gmail.com>; Tom Jones ; >>>>>>>>>>>> Denis ; Justin Richer >>>>>>>>>>>> *Subject:* Re: [GNAP] Review of >>>>>>>>>>>> draft-ietf-gnap-core-protocol-00 >>>>>>>>>>>> >>>>>>>>>>>> Would make sense, but not so easy as we rely heavily on HTTP. >>>>>>>>>>>> Hence the discussion about deep links and so on. >>>>>>>>>>>> >>>>>>>>>>>> An alternative might be provided by wasm/wasi (running a local >>>>>>>>>>>> sandbox on your phone, for your own AS), but it's really early= stage. This >>>>>>>>>>>> also poses another question that Denis has put forward, i.e. h= ow do we >>>>>>>>>>>> handle the multiple AS scenario (likely to occur then). >>>>>>>>>>>> >>>>>>>>>>>> Fabien >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha < >>>>>>>>>>>> fpo@adorsys.de> wrote: >>>>>>>>>>>> >>>>>>>>>>>> We are drifting away from the original problem space. >>>>>>>>>>>> >>>>>>>>>>>> - My original mention was about the "POST" request, that >>>>>>>>>>>> subsumes that the "AS" is a "Server". Designing a new proto= col, we cannot >>>>>>>>>>>> afford this limitation. >>>>>>>>>>>> - I just mentioned SIOP to show a known and closed example? >>>>>>>>>>>> Let us not focus on the device local discovery scheme (like= openid:) for >>>>>>>>>>>> now. >>>>>>>>>>>> - As capability of holding private keys on user device >>>>>>>>>>>> evolves, server-based issuing of token will be fading out g= iving way to >>>>>>>>>>>> device local generation of token. >>>>>>>>>>>> >>>>>>>>>>>> While designing GNAP, let us assume the AS-Role can be >>>>>>>>>>>> exercised on a user device and design the protocol to honor th= at. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> /Francis >>>>>>>>>>>> ------------------------------ >>>>>>>>>>>> *From:* TXAuth on behalf of Dick >>>>>>>>>>>> Hardt >>>>>>>>>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>>>>>>>>>> *To:* Tom Jones >>>>>>>>>>>> *Cc:* Fabien Imbault ; Denis < >>>>>>>>>>>> denis.ietf@free.fr>; GNAP Mailing List ; >>>>>>>>>>>> Justin Richer >>>>>>>>>>>> *Subject:* Re: [GNAP] Review of >>>>>>>>>>>> draft-ietf-gnap-core-protocol-00 >>>>>>>>>>>> >>>>>>>>>>>> Got it. >>>>>>>>>>>> >>>>>>>>>>>> So web apps invoke a openid: deep link and hope there is an ap= p >>>>>>>>>>>> to handle the openid: scheme? ... and that it is the user's wa= llet rather >>>>>>>>>>>> than some malware that has registered openid: on the mobile de= vice? >>>>>>>>>>>> >>>>>>>>>>>> A native app can attempt to open a deep link associated with a= n >>>>>>>>>>>> app, and will fail if the app is not there. If the app is ther= e, it will be >>>>>>>>>>>> opened, so this can't be used to silently test if an app is pr= esent, but it >>>>>>>>>>>> does allow a native app to provide an alternative experience i= f an app is >>>>>>>>>>>> not present. I don't think this works with custom schemes ... = and I don't >>>>>>>>>>>> know how it could work from a web app on the phone with the cu= rrent Safari >>>>>>>>>>>> APIs. >>>>>>>>>>>> >>>>>>>>>>>> Apple warns against using custom schemes [1] ... but perhaps >>>>>>>>>>>> they can be convinced to make openid: a managed scheme similar= to mailto:, >>>>>>>>>>>> tel:, sms:, facetime: ? >>>>>>>>>>>> >>>>>>>>>>>> [1] >>>>>>>>>>>> https://developer.apple.com/documentation/xcode/allowing_apps_= and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_= app >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> You are - that is not standard which is opeind:// >>>>>>>>>>>> This is the one step that still needs to be optimized for SIOP >>>>>>>>>>>> to have good UX. >>>>>>>>>>>> Peace ..tom >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt < >>>>>>>>>>>> dick.hardt@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Tom >>>>>>>>>>>> >>>>>>>>>>>> I watched your video (I watched at 2X speed) >>>>>>>>>>>> >>>>>>>>>>>> Looks like the employment website app that is using >>>>>>>>>>>> localhost:8765 to communicate with the wallet. Am I correct? >>>>>>>>>>>> >>>>>>>>>>>> /Dick >>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones < >>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Well, here's a demo. Note that in this case the AS is not >>>>>>>>>>>> online all of the time, so it is really implicit flow and the = OIDC id-token >>>>>>>>>>>> comes from the siop device directly. >>>>>>>>>>>> (whether this is front-channel or back channel is no longer an >>>>>>>>>>>> interesting question.) >>>>>>>>>>>> Now if an always-on AS is required, that is possible, but >>>>>>>>>>>> probably beyond the scope of this effort and would require som= ething like >>>>>>>>>>>> an agent-in-the-sky (with diamonds). >>>>>>>>>>>> here is the link to the 9 min video https://youtu.be >>>>>>>>>>>> /Tq4hw7X5SW0 >>>>>>>>>>>> >>>>>>>>>>>> Peace ..tom >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Ultimately, in most situations like these in the real world, >>>>>>>>>>>> the hurdle isn=E2=80=99t technical compatibility so much as it= is trust >>>>>>>>>>>> compatibility. The RP (client) needs to have some incentive to= trust the >>>>>>>>>>>> assertions and identity information that=E2=80=99s coming from= the AS. The same is >>>>>>>>>>>> true for an RS trusting tokens from the AS. The hard question = is less =E2=80=9Chow=E2=80=9D >>>>>>>>>>>> to do that (which SSI answers), but more =E2=80=9Cwhy=E2=80=9D= to do that (which SSI >>>>>>>>>>>> doesn=E2=80=99t answer very well, because it=E2=80=99s a hard = question). >>>>>>>>>>>> >>>>>>>>>>>> Still: it=E2=80=99s definitely a question about how to support= this =E2=80=9CAS >>>>>>>>>>>> on device=E2=80=9D element. We=E2=80=99ve got the start of it = more than OAuth2/OIDC have by >>>>>>>>>>>> allowing the bootstrap of the process from a starting call: th= e interaction >>>>>>>>>>>> and continuation URIs handed back by the AS don=E2=80=99t need= to be the same URIs >>>>>>>>>>>> that the client starts with, so just like SIOP the process can= start in >>>>>>>>>>>> HTTP and potentially move to other communication channels. A m= ajor >>>>>>>>>>>> difference is that we aren=E2=80=99t dependent on the assumpti= on that the user will >>>>>>>>>>>> always be in a browser at some stage, and so the whole raft of >>>>>>>>>>>> front-channel messages that SIOP relies on doesn=E2=80=99t fly= . That said, we=E2=80=99ve >>>>>>>>>>>> got an opportunity to more explicitly open up alternative comm= unication >>>>>>>>>>>> channels here, and that=E2=80=99s something I=E2=80=99d like t= o see engineered, even if >>>>>>>>>>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete = proposal as to how that would >>>>>>>>>>>> work over specific protocols, starting with what we=E2=80=99ve= got today. >>>>>>>>>>>> >>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>> >>>>>>>>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault < >>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Denis, hi Francis, >>>>>>>>>>>> >>>>>>>>>>>> At some point integration with SSI (on the authentication side= ) >>>>>>>>>>>> will probably occur, including amongst other possibilities SIO= P (since they >>>>>>>>>>>> work with OpenID a part of the work will probably be made easi= er). >>>>>>>>>>>> >>>>>>>>>>>> That being said, Denis is right. It's not an AS. Technically >>>>>>>>>>>> it's entirely possible to rely on a decentralized wallet (for = instance on >>>>>>>>>>>> your phone) and a centralized AS. I know of a few studies on h= ow to >>>>>>>>>>>> decentralize the AS itself (for instance >>>>>>>>>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized= -02 >>>>>>>>>>>> ). >>>>>>>>>>>> Maybe it exists, but I'm still looking for real scenarios (or >>>>>>>>>>>> even architectures) where an AS is deployed directly on a phon= e, and under >>>>>>>>>>>> the sole authority of the RO, while being compatible with the = rest of the >>>>>>>>>>>> world. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Fabien >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hello Francis, >>>>>>>>>>>> >>>>>>>>>>>> See two comments in line. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> B) Current Document >>>>>>>>>>>> >>>>>>>>>>>> Roles description shall not hold any assumption on the physica= l >>>>>>>>>>>> structure of the party fulfilling the roles. >>>>>>>>>>>> [FI] not sure what you mean >>>>>>>>>>>> >>>>>>>>>>>> [FP] for example, we assume the AS is a server! In most SSI >>>>>>>>>>>> based use cases, the AS will be running on the user device. Se= e SIOP ( >>>>>>>>>>>> https://identity.foundation/did-siop/). >>>>>>>>>>>> >>>>>>>>>>>> I browsed through the two drafts, i.e. : >>>>>>>>>>>> >>>>>>>>>>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, >>>>>>>>>>>> data model, and representations W3C Working Draft 08 Novemb= er 2020 >>>>>>>>>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF >>>>>>>>>>>> Working Group Draft >>>>>>>>>>>> >>>>>>>>>>>> At no place within these two documents, it is possible to >>>>>>>>>>>> imagine that "the AS will be running on the user device". >>>>>>>>>>>> >>>>>>>>>>>> From section 3 of the DIF Working Group Draft: >>>>>>>>>>>> >>>>>>>>>>>> "Unlike the OIDC Authorization Code Flow as per >>>>>>>>>>>> [OIDC.Core], the SIOP will not return an access token to the R= P". >>>>>>>>>>>> >>>>>>>>>>>> An Identity Wallet is not an AS. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Roles: >>>>>>>>>>>> -> grant endpoint of the AS: Why is this a post request? This >>>>>>>>>>>> eliminates the chance of having user device hosted AS (no serv= er). >>>>>>>>>>>> [FI] what would you propose instead? >>>>>>>>>>>> Would also be interested to understand better the deployment >>>>>>>>>>>> model when there is no server. That's something that was discu= ssed several >>>>>>>>>>>> times but I'm still missing the underlying architecture and us= e case. >>>>>>>>>>>> >>>>>>>>>>>> [FP] See above (SIOP). There will be a lot of identity wallet= s >>>>>>>>>>>> operated on end user device. >>>>>>>>>>>> >>>>>>>>>>>> See the above comment. Please, do not confuse an Identity >>>>>>>>>>>> Wallet with an Authentication Server (AS). >>>>>>>>>>>> >>>>>>>>>>>> Denis >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it >>>>>>>>>>>> authorize the request or the access to a resource? >>>>>>>>>>>> [FI] yes, we should make the wording clearer >>>>>>>>>>>> >>>>>>>>>>>> Missing Section Interactions: >>>>>>>>>>>> --> This section shall introduce the notion of interaction >>>>>>>>>>>> before we start listing interaction types. >>>>>>>>>>>> [FI] yes >>>>>>>>>>>> >>>>>>>>>>>> Interaction Types: >>>>>>>>>>>> --> I prefer a classification with Redirect, Decoupled and >>>>>>>>>>>> Embedded is. In the draft, we have one redirect and 2 decouple= interactions >>>>>>>>>>>> and nothing else. >>>>>>>>>>>> [FI] this should be handled as a specific discussion item. As = a >>>>>>>>>>>> reminder, how would you define embedded? >>>>>>>>>>>> >>>>>>>>>>>> In practice there's at least these modes: >>>>>>>>>>>> - redirect and redirect back >>>>>>>>>>>> - redirect to different browser or device >>>>>>>>>>>> - user code >>>>>>>>>>>> - CIBA >>>>>>>>>>>> >>>>>>>>>>>> [FP] This classification is limited. >>>>>>>>>>>> >>>>>>>>>>>> - Redirect: same device, same or different user agents >>>>>>>>>>>> (browser, mobile app, desktop app, ...) >>>>>>>>>>>> - Decoupled: different devices >>>>>>>>>>>> - Embedded : RC carries RO authorization to AS >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Resource Access Request vs. Resource Request >>>>>>>>>>>> --> Both are mixed up. No clarification of the context of each >>>>>>>>>>>> section. >>>>>>>>>>>> [FI] could you clarify what you'd expect. Btw on this topic, >>>>>>>>>>>> there's a more general discussion on whether we should make a = distinction >>>>>>>>>>>> or not. >>>>>>>>>>>> >>>>>>>>>>>> [FP]: Here: >>>>>>>>>>>> >>>>>>>>>>>> - Resource Access Request: Requesting Access to a resource. >>>>>>>>>>>> Response is an access token (or any type of grant) >>>>>>>>>>>> - Resource Request: Request the resource. Response is the >>>>>>>>>>>> resource (or a corresponding execution) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Token Content Negotiation >>>>>>>>>>>> --> Not expressed as such. This is central to GNAP and not >>>>>>>>>>>> represented enough in the document. >>>>>>>>>>>> [FI] right. This should be a specific discussion item. >>>>>>>>>>>> >>>>>>>>>>>> Requesting "User" Information >>>>>>>>>>>> we identify two types of users: RQ and RO. It will be better >>>>>>>>>>>> not to refer to a user in this draft, but either to a RQ or an= RO. >>>>>>>>>>>> [FI] yes that would avoid potential misunderstandings. Althoug= h >>>>>>>>>>>> in the end, people will translate RQ into user or end-user mos= t of the >>>>>>>>>>>> time. Cf in definition, currently we have Requesting Party >>>>>>>>>>>> (RQ, aka "user") >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Interaction Again >>>>>>>>>>>> -> For each interaction type, we will have to describe the >>>>>>>>>>>> protocol flow and the nature and behavior of involved Roles (P= arties), >>>>>>>>>>>> Elements, Requests. >>>>>>>>>>>> [FI] yes >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> [FP] Will these and into tickets? >>>>>>>>>>>> >>>>>>>>>>>> Best regards. >>>>>>>>>>>> /Francis >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>>> >>>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >> --000000000000259e6305ba94ffdd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,=C2=A0

Thanks, your responses made it c= learer for me what you expect from an AS deployed on a mobile.=C2=A0
<= div dir=3D"auto">
I think we're on the right= path to meet the rest of your concerns. There are already a few items on t= hese:
- privacy preserving techniques have been disc= ussed and are likely to be included (I think). It's been recognized as = a core concern=C2=A0
- not exactly sure the meaning = you give to discovery here (it's already been used in the WG but with a= different meaning I believe). The request or the continuation api provide = entry points to pay attention to.=C2=A0

Is that enough for your use case ? Do you need something else ? (like SS= E?)

Cheers
Fabien=C2=A0

Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, = Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit=C2=A0:
discovery is the prime problem.= =C2=A0 What causes the wallet/AS to wake up and pay attention. How does the= RP know what to ask for without violating user privacy rights?

CHAPI would be ok i guess, but that requires cred man to be fixed. = Not sure if it fixes discovery or privacy even then.

Be= the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 12:45 PM Justin Richer <jricher@mit.edu= > wrote:
Tom, what additional functionality do you see that a browser would need to= support in order for GNAP to be adopted? For the elements of the core prot= ocol today, nothing is needed to change within the browsers =E2=80=94 every= thing is built on existing functions. GNAP uses browsers as a tool, and I w= ould argue depends on them even less so than OAuth 2 does. Extensions could= use browser functionality, like using CHAPI to pass interaction elements, = but the core protocol functions on vanilla browsers today.

=C2=A0=E2=80=94 Justin

On Feb= 4, 2021, at 3:20 PM, Tom Jones <thomasclinganjones@gmail.com> w= rote:

i assumed that the wallet (aka AS) nee= ded to be a native app, not a PWA (which can come from a traditional web se= rver).
There are folks, lke Kim C, who are working on a PWA, but i agre= e the blocks there seem to be large.
THe blocks on a native app a= re simple, easy to describe, and easy to ask the browser guys to fix. Not s= ure if they care tho.
I have trouble seeing a path to GNAP adopti= on for retail customers w/o some browser support.
That's why = i am mostly=C2=A0silent here.

Be th= e change you want to see in the world ..tom
<= br>

On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault <fabien.imbault@gma= il.com> wrote:
Fair enough. But loopback limits a lot what you can= do... Just for debug it's a pain.=C2=A0
But as soon a= s you try more, it's a bit crazy. Fun to test ipv6 (luckily supported b= y my ISP) and ddns. But it feels really hacky.=C2=A0
Also deployment is a pain, compared to a traditional webserver.=C2=A0

Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit= =C2=A0:
doesn't work very well on windows uwp. works fine on smartphon= es
Be the change you want to see in the w= orld ..tom


On Thu, Feb 4, 2021 at 1= 1:18 AM Justin Richer <jriche= r@mit.edu> wrote:
OK, thanks =E2=80=94 in that case, there are no changes at = all to GNAP, which is already HTTP driven. The harder parts tend to be wher= e you can=E2=80=99t (or don=E2=80=99t want to) use something like that.
=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 2:16 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:
yes, loopback

<= div>
Be the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:01 AM Justin Richer <= jricher@mit.edu> wrote:
Tom, can you= expand on how exactly the back-channel =C2=A0communication works between o= n-device components? Do you use HTTP locally?

Thanks,
=C2=A0=E2=80=94 Justin

O= n Feb 4, 2021, at 1:03 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

=
Justin's analysis of use of the front channel is = misleading.
It could equally be argued that what i have done is install= ed an AS on the phone and the communications with it & the PR is back c= hannel.
Basically the point is that the old OIDC paradigms are no= longer valid.
Be the change you want to see i= n the world ..tom


On Thu, Feb 4, 20= 21 at 7:47 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Yes, issue (#168)=C2= =A0message based interaction / DIDComm is a tentative alternative mecanism = for the interaction part. Not sure how that would work in details=C2=A0thou= gh, prototyping will probably help here.
Token delivery=C2=A0through co= ntinuation seems fine to me. The client will probably have to wait for the = next polling before it receives a token issued as the result of an asynchro= nous interaction, but that's not a big issue.

= But the AS on the phone seems like a harder nut to crack, at least at first= sight. I think that would be awesome, but it gives me headaches, so I thin= k I'll work on easier stuff right now ;-)

Fabi= en=C2=A0=C2=A0

On Thu, Feb 4, 2021 at 4:30 PM Justin Richer <jricher@mit.edu> wrote:
=
One of the big= gest drawbacks of the current app-centric approaches in OIDC (self-issued O= P, or SIOP) is that they depend on using the front channel and browser redi= rects to pass everything, which is something that GNAP is deliberately gett= ing away from by starting in the back channel.

That said= , once a request is kicked off in GNAP, the interaction and fulfillment can= happen through any number of means. Part of the work that=E2=80=99s being = done with the =E2=80=9Cinteraction=E2=80=9D section is going to help facili= tate this, and I think that there are some other potential branches here.

Token delivery is where things get extra weird thou= gh =E2=80=94 we are explicitly not delivering tokens in the front channel i= n the core of GNAP, we=E2=80=99re using the response from the continuation = API. One idea (that isn=E2=80=99t particularly well thought out and hasn=E2= =80=99t been implemented at all) is to have an extension declare an alterna= tive response from the =E2=80=9Ccontinue=E2=80=9D section that=E2=80=99s de= fined today, which points to the GNPA continuation API. If an extension def= ines some alternative way to deliver tokens, that could live alongside a co= ntinuation API and the client could indicate support for it in its initial = request.

In any event, alternative interaction and= delivery methods are important, and even if we aren=E2=80=99t going to sup= port every last one of them directly, the protocol design should at least b= e aware of them.

=C2=A0=E2=80=94 Justin
On Feb 4, 2021, at 8:35 AM, Fabien Imbault= <fabien.imbault@gma= il.com> wrote:

Hi Tom,=C2=A0

=
Sure, any experience on that would be greatly appreciated, we= 9;re calling for help here (the point being that I suspect what they're= doing is not trivial).

Fabien

On Thu, Feb 4,= 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
I've had such= an app working for over a year. There are issues which are being addressed= by the browser Interaction team of oidc.

thx ..Tom (mobile)

On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Fra= ncis,=C2=A0

I've tried a few things with regards to = using the AS on a phone, but it's really quite=C2=A0complex.=C2=A0

Making that run on a phone comes with quite a bit of t= rouble. The most difficult part if that we'd need to use a secure eleme= nt, but just installing and hosting a http server securely is not a standar= d setup at all. I suggest interested people step in to work on this, as we = already have a lot of work for the (more usual) server case and already han= dle a privacy preserving scheme.=C2=A0

Please let = us know what you think.

Cheers,
Fabien= =C2=A0

On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
=
Hi Francis,

I've thought a bit more to what you said. I think I'll give it= a try as a separate experiment (in code, not in theory). Not that I would = expect it to be included in GNAP, but I kind of like the idea :-)

The direct impact for GNAP would = be to think about multiple ASs.=C2=A0

Will let you know.=C2=A0

Fabien=C2=A0


Le mer. 18 nov. 2020 =C3=A0 13:06, Francis P= ouatcha <fpo@adorsy= s.de> a =C3=A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"m_-8218552788289986907m_-8518815978092546954m_3550419800836567560m_-825= 1187544229342067m_6649396458130137896m_3308803089207789488m_-43543655485961= 4529m_2888166142485750597gmail-m_7901394266816005280gmail-m_-67181849994525= 12077m_-3004232231493229381m_-8862550958674531306m_4552653984562635461m_387= 929924441527190m_6662104191003806385gmail-m_-542839070341023388gmail-m_-617= 6056956474019294gmail-m_-3037161202240578685gmail-m_-7520389457378808664gma= il-m_-3342024782330569254m_8014700032835912204gmail-m_142651873244800559m_8= 348797445460806175LPlnk338391" rel=3D"noreferrer noreferrer noreferrer nore= ferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer no= referrer noreferrer noreferrer noreferrer" target=3D"_blank">https://github= .com/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <fabien.= imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>; Dick Hardt <dick.hardt@gmail.com&= gt;; Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@f= ree.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@adorsys.de<= /a>> wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
Fro= m: TXAuth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.iet= f@free.fr>; GNAP Mailing List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomascl= inganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail= .com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomascli= nganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin


Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https= ://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr&= gt; wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/= ).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= [FP]: Her= e:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TX= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--000000000000259e6305ba94ffdd-- From nobody Fri Feb 5 07:33:49 2021 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 14DA53A127A for ; Fri, 5 Feb 2021 07:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 lt-v6oS9CtpU for ; Fri, 5 Feb 2021 07:33:43 -0800 (PST) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 00A843A1277 for ; Fri, 5 Feb 2021 07:33:42 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id k25so5128221otb.4 for ; Fri, 05 Feb 2021 07:33:42 -0800 (PST) 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=3nnMpROJVBKfnZrz7wIr5v5j7Y9cj3Pp8bMKwiKzAY0=; b=EaQziHoB/bP6g5OqtakQiPodHffRb2d7dN7HpSQ/mRiMnFpYEZMGD5Z7C1EfojNWq/ rKfAB1phFwUR8E+A1z2elG/oUcawxi6SC8e8vu5cEGMnBdIKnvg9qEw2wQeGjV8VFRXC u1I5K5GVWIIkDQSQlv7EZzRdZXcSESNGhKS1ppCKIDyqUAdT8AVEOtAJNXTV9FLNfWLl 8qRRm0pdnXOpNSB3WUPWUIwzPDvkHYgmFGvMbzjt+agTEtfV/X5iuGJKyg8H1gUzsxFu yqCxLxaR1VNXILx2UPqS22D6/W8yFPAJNqYaPy/p32r4Offnz0afJwEy/y9ybwi91QFI Wa4g== 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=3nnMpROJVBKfnZrz7wIr5v5j7Y9cj3Pp8bMKwiKzAY0=; b=eT6eg+tvUBNFXaDFoOeLDbWnVF7oNbMZ7kKSKxEZwdFk/BTqar6EmNvQn6OZCpStWz NbwHhinbpGUW+bGz2Pu7xHM8S91qPJnzxTsoSttIvFmS3tni61jZl2bh7Wg8YYQBLILI sWcfQhM3Vz9fR+XZkYt2CRJhJFyQYYu+RdDhNJ8SDLoH4wY9MLXQ/cNJTRF8MPc2OHdb H9/jJQ9rE/pEyBw/9SqeEaeqQCa60o/IoAs15ZkdTvWgnyS+S9ZY7M3PHgtd20wcK651 ohbKBPl6pvN6YWkUuGrC53sGxnTbvqbWn+ndjNDaT2lis+jQ/YwEKa0dtshYJiu4GJqN SyLg== X-Gm-Message-State: AOAM530YK+gle6Ie6nqimVIgmRR0oZ8MvweYRY86j8yLJr+EevhR2jIL mokEOQUgNKmzDcNcIy3IHeWtTK/O4L7VVbYMPa8= X-Google-Smtp-Source: ABdhPJxtvv8QNX0WblnZgjt0yrstfU5yUC7o/HR8oxIHq1Kt6jfRyOztPN5foUkC6hTTMppdTMZ7qX8dOhErgjTTGbg= X-Received: by 2002:a9d:3b87:: with SMTP id k7mr3758497otc.143.1612539222042; Fri, 05 Feb 2021 07:33:42 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> <77D1AE7B-076F-4095-8FAA-7C35D74614BD@mit.edu> In-Reply-To: From: Tom Jones Date: Fri, 5 Feb 2021 07:33:29 -0800 Message-ID: To: Fabien Imbault Cc: Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="000000000000842bf805ba988b99" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 15:33:47 -0000 --000000000000842bf805ba988b99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If you mean can GNAP work on old fashioned apps running with existing browsers and existing identity providers, then yes, i guess you are ok. If you want to work on apps where the user is in control of authn and authz, then no, GNAP cannot work. It is not alone in that OIDC wont work there either. Be the change you want to see in the world ..tom On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault wrote: > Hi Tom, > > Thanks, your responses made it clearer for me what you expect from an AS > deployed on a mobile. > > I think we're on the right path to meet the rest of your concerns. There > are already a few items on these: > - privacy preserving techniques have been discussed and are likely to be > included (I think). It's been recognized as a core concern > - not exactly sure the meaning you give to discovery here (it's already > been used in the WG but with a different meaning I believe). The request = or > the continuation api provide entry points to pay attention to. > > Is that enough for your use case ? Do you need something else ? (like SSE= ?) > > Cheers > Fabien > > Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom Jones a > =C3=A9crit : > >> discovery is the prime problem. What causes the wallet/AS to wake up an= d >> pay attention. How does the RP know what to ask for without violating us= er >> privacy rights? >> >> CHAPI would be ok i guess, but that requires cred man to be fixed. Not >> sure if it fixes discovery or privacy even then. >> >> Be the change you want to see in the world ..tom >> >> >> On Thu, Feb 4, 2021 at 12:45 PM Justin Richer wrote: >> >>> Tom, what additional functionality do you see that a browser would need >>> to support in order for GNAP to be adopted? For the elements of the cor= e >>> protocol today, nothing is needed to change within the browsers =E2=80= =94 >>> everything is built on existing functions. GNAP uses browsers as a tool= , >>> and I would argue depends on them even less so than OAuth 2 does. >>> Extensions could use browser functionality, like using CHAPI to pass >>> interaction elements, but the core protocol functions on vanilla browse= rs >>> today. >>> >>> =E2=80=94 Justin >>> >>> On Feb 4, 2021, at 3:20 PM, Tom Jones >>> wrote: >>> >>> i assumed that the wallet (aka AS) needed to be a native app, not a PWA >>> (which can come from a traditional web server). >>> There are folks, lke Kim C, who are working on a PWA, but i agree the >>> blocks there seem to be large. >>> THe blocks on a native app are simple, easy to describe, and easy to as= k >>> the browser guys to fix. Not sure if they care tho. >>> I have trouble seeing a path to GNAP adoption for retail customers w/o >>> some browser support. >>> That's why i am mostly silent here. >>> >>> Be the change you want to see in the world ..tom >>> >>> >>> On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault >>> wrote: >>> >>>> Fair enough. But loopback limits a lot what you can do... Just for >>>> debug it's a pain. >>>> But as soon as you try more, it's a bit crazy. Fun to test ipv6 >>>> (luckily supported by my ISP) and ddns. But it feels really hacky. >>>> Also deployment is a pain, compared to a traditional webserver. >>>> >>>> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones >>>> a =C3=A9crit : >>>> >>>>> doesn't work very well on windows uwp. works fine on smartphones >>>>> Be the change you want to see in the world ..tom >>>>> >>>>> >>>>> On Thu, Feb 4, 2021 at 11:18 AM Justin Richer wrote= : >>>>> >>>>>> OK, thanks =E2=80=94 in that case, there are no changes at all to GN= AP, which >>>>>> is already HTTP driven. The harder parts tend to be where you can=E2= =80=99t (or >>>>>> don=E2=80=99t want to) use something like that. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Feb 4, 2021, at 2:16 PM, Tom Jones >>>>>> wrote: >>>>>> >>>>>> yes, loopback >>>>>> >>>>>> Be the change you want to see in the world ..tom >>>>>> >>>>>> >>>>>> On Thu, Feb 4, 2021 at 11:01 AM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> Tom, can you expand on how exactly the back-channel communication >>>>>>> works between on-device components? Do you use HTTP locally? >>>>>>> >>>>>>> Thanks, >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Feb 4, 2021, at 1:03 PM, Tom Jones >>>>>>> wrote: >>>>>>> >>>>>>> Justin's analysis of use of the front channel is misleading. >>>>>>> It could equally be argued that what i have done is installed an AS >>>>>>> on the phone and the communications with it & the PR is back channe= l. >>>>>>> Basically the point is that the old OIDC paradigms are no longer >>>>>>> valid. >>>>>>> Be the change you want to see in the world ..tom >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Yes, issue (#168) message based interaction / DIDComm is a >>>>>>>> tentative alternative mecanism for the interaction part. Not sure = how that >>>>>>>> would work in details though, prototyping will probably help here. >>>>>>>> Token delivery through continuation seems fine to me. The client >>>>>>>> will probably have to wait for the next polling before it receives= a token >>>>>>>> issued as the result of an asynchronous interaction, but that's no= t a big >>>>>>>> issue. >>>>>>>> >>>>>>>> But the AS on the phone seems like a harder nut to crack, at least >>>>>>>> at first sight. I think that would be awesome, but it gives me hea= daches, >>>>>>>> so I think I'll work on easier stuff right now ;-) >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> One of the biggest drawbacks of the current app-centric approache= s >>>>>>>>> in OIDC (self-issued OP, or SIOP) is that they depend on using th= e front >>>>>>>>> channel and browser redirects to pass everything, which is someth= ing that >>>>>>>>> GNAP is deliberately getting away from by starting in the back ch= annel. >>>>>>>>> >>>>>>>>> That said, once a request is kicked off in GNAP, the interaction >>>>>>>>> and fulfillment can happen through any number of means. Part of t= he work >>>>>>>>> that=E2=80=99s being done with the =E2=80=9Cinteraction=E2=80=9D = section is going to help >>>>>>>>> facilitate this, and I think that there are some other potential = branches >>>>>>>>> here. >>>>>>>>> >>>>>>>>> Token delivery is where things get extra weird though =E2=80=94 w= e are >>>>>>>>> explicitly not delivering tokens in the front channel in the core= of GNAP, >>>>>>>>> we=E2=80=99re using the response from the continuation API. One i= dea (that isn=E2=80=99t >>>>>>>>> particularly well thought out and hasn=E2=80=99t been implemented= at all) is to >>>>>>>>> have an extension declare an alternative response from the =E2=80= =9Ccontinue=E2=80=9D >>>>>>>>> section that=E2=80=99s defined today, which points to the GNPA co= ntinuation API. If >>>>>>>>> an extension defines some alternative way to deliver tokens, that= could >>>>>>>>> live alongside a continuation API and the client could indicate s= upport for >>>>>>>>> it in its initial request. >>>>>>>>> >>>>>>>>> In any event, alternative interaction and delivery methods are >>>>>>>>> important, and even if we aren=E2=80=99t going to support every l= ast one of them >>>>>>>>> directly, the protocol design should at least be aware of them. >>>>>>>>> >>>>>>>>> =E2=80=94 Justin >>>>>>>>> >>>>>>>>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>> Hi Tom, >>>>>>>>> >>>>>>>>> Sure, any experience on that would be greatly appreciated, we're >>>>>>>>> calling for help here (the point being that I suspect what they'r= e doing is >>>>>>>>> not trivial). >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones < >>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> I've had such an app working for over a year. There are issues >>>>>>>>>> which are being addressed by the browser Interaction team of oid= c. >>>>>>>>>> >>>>>>>>>> thx ..Tom (mobile) >>>>>>>>>> >>>>>>>>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Francis, >>>>>>>>>>> >>>>>>>>>>> I've tried a few things with regards to using the AS on a phone= , >>>>>>>>>>> but it's really quite complex. >>>>>>>>>>> >>>>>>>>>>> Making that run on a phone comes with quite a bit of trouble. >>>>>>>>>>> The most difficult part if that we'd need to use a secure eleme= nt, but just >>>>>>>>>>> installing and hosting a http server securely is not a standard= setup at >>>>>>>>>>> all. I suggest interested people step in to work on this, as we= already >>>>>>>>>>> have a lot of work for the (more usual) server case and already= handle a >>>>>>>>>>> privacy preserving scheme. >>>>>>>>>>> >>>>>>>>>>> Please let us know what you think. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Francis, >>>>>>>>>>>> >>>>>>>>>>>> I've thought a bit more to what you said. I think I'll give it >>>>>>>>>>>> a try as a separate experiment (in code, not in theory). Not t= hat I would >>>>>>>>>>>> expect it to be included in GNAP, but I kind of like the idea = :-) >>>>>>>>>>>> >>>>>>>>>>>> The direct impact for GNAP would be to think about multiple >>>>>>>>>>>> ASs. >>>>>>>>>>>> >>>>>>>>>>>> Will let you know. >>>>>>>>>>>> >>>>>>>>>>>> Fabien >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha >>>>>>>>>>>> a =C3=A9crit : >>>>>>>>>>>> >>>>>>>>>>>>> It would be nice if the protocol was designed at many layers >>>>>>>>>>>>> of abstraction. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - The first layer shall design abstract protocol flows, >>>>>>>>>>>>> without specification of the mode and mechanism of interac= tion. >>>>>>>>>>>>> - The second layer can instantiate the first layer for >>>>>>>>>>>>> dedicated interaction. Here we can talk http, we can defin= e interactions >>>>>>>>>>>>> that presume server based token generation, we can define = interaction that >>>>>>>>>>>>> run on user device based token generation. >>>>>>>>>>>>> >>>>>>>>>>>>> This is also the fundament of the structure I proposed for th= e >>>>>>>>>>>>> spec ( >>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30)= . >>>>>>>>>>>>> >>>>>>>>>>>>> /Francis >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>> *From:* Fabien Imbault >>>>>>>>>>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>>>>>>>>>>> *To:* Francis Pouatcha >>>>>>>>>>>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>>>>>>>>>>> dick.hardt@gmail.com>; Tom Jones ; >>>>>>>>>>>>> Denis ; Justin Richer >>>>>>>>>>>>> *Subject:* Re: [GNAP] Review of >>>>>>>>>>>>> draft-ietf-gnap-core-protocol-00 >>>>>>>>>>>>> >>>>>>>>>>>>> Would make sense, but not so easy as we rely heavily on HTTP. >>>>>>>>>>>>> Hence the discussion about deep links and so on. >>>>>>>>>>>>> >>>>>>>>>>>>> An alternative might be provided by wasm/wasi (running a loca= l >>>>>>>>>>>>> sandbox on your phone, for your own AS), but it's really earl= y stage. This >>>>>>>>>>>>> also poses another question that Denis has put forward, i.e. = how do we >>>>>>>>>>>>> handle the multiple AS scenario (likely to occur then). >>>>>>>>>>>>> >>>>>>>>>>>>> Fabien >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha < >>>>>>>>>>>>> fpo@adorsys.de> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> We are drifting away from the original problem space. >>>>>>>>>>>>> >>>>>>>>>>>>> - My original mention was about the "POST" request, that >>>>>>>>>>>>> subsumes that the "AS" is a "Server". Designing a new prot= ocol, we cannot >>>>>>>>>>>>> afford this limitation. >>>>>>>>>>>>> - I just mentioned SIOP to show a known and closed >>>>>>>>>>>>> example? Let us not focus on the device local discovery sc= heme (like >>>>>>>>>>>>> openid:) for now. >>>>>>>>>>>>> - As capability of holding private keys on user device >>>>>>>>>>>>> evolves, server-based issuing of token will be fading out = giving way to >>>>>>>>>>>>> device local generation of token. >>>>>>>>>>>>> >>>>>>>>>>>>> While designing GNAP, let us assume the AS-Role can be >>>>>>>>>>>>> exercised on a user device and design the protocol to honor t= hat. >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> /Francis >>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>> *From:* TXAuth on behalf of Dick >>>>>>>>>>>>> Hardt >>>>>>>>>>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>>>>>>>>>>> *To:* Tom Jones >>>>>>>>>>>>> *Cc:* Fabien Imbault ; Denis < >>>>>>>>>>>>> denis.ietf@free.fr>; GNAP Mailing List ; >>>>>>>>>>>>> Justin Richer >>>>>>>>>>>>> *Subject:* Re: [GNAP] Review of >>>>>>>>>>>>> draft-ietf-gnap-core-protocol-00 >>>>>>>>>>>>> >>>>>>>>>>>>> Got it. >>>>>>>>>>>>> >>>>>>>>>>>>> So web apps invoke a openid: deep link and hope there is an >>>>>>>>>>>>> app to handle the openid: scheme? ... and that it is the user= 's wallet >>>>>>>>>>>>> rather than some malware that has registered openid: on the m= obile device? >>>>>>>>>>>>> >>>>>>>>>>>>> A native app can attempt to open a deep link associated with >>>>>>>>>>>>> an app, and will fail if the app is not there. If the app is = there, it will >>>>>>>>>>>>> be opened, so this can't be used to silently test if an app i= s present, but >>>>>>>>>>>>> it does allow a native app to provide an alternative experien= ce if an app >>>>>>>>>>>>> is not present. I don't think this works with custom schemes = ... and I >>>>>>>>>>>>> don't know how it could work from a web app on the phone with= the current >>>>>>>>>>>>> Safari APIs. >>>>>>>>>>>>> >>>>>>>>>>>>> Apple warns against using custom schemes [1] ... but perhaps >>>>>>>>>>>>> they can be convinced to make openid: a managed scheme simila= r to mailto:, >>>>>>>>>>>>> tel:, sms:, facetime: ? >>>>>>>>>>>>> >>>>>>>>>>>>> [1] >>>>>>>>>>>>> https://developer.apple.com/documentation/xcode/allowing_apps= _and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your= _app >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> You are - that is not standard which is opeind:// >>>>>>>>>>>>> This is the one step that still needs to be optimized for SIO= P >>>>>>>>>>>>> to have good UX. >>>>>>>>>>>>> Peace ..tom >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt < >>>>>>>>>>>>> dick.hardt@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Tom >>>>>>>>>>>>> >>>>>>>>>>>>> I watched your video (I watched at 2X speed) >>>>>>>>>>>>> >>>>>>>>>>>>> Looks like the employment website app that is using >>>>>>>>>>>>> localhost:8765 to communicate with the wallet. Am I correct? >>>>>>>>>>>>> >>>>>>>>>>>>> /Dick >>>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones < >>>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Well, here's a demo. Note that in this case the AS is not >>>>>>>>>>>>> online all of the time, so it is really implicit flow and the= OIDC id-token >>>>>>>>>>>>> comes from the siop device directly. >>>>>>>>>>>>> (whether this is front-channel or back channel is no longer a= n >>>>>>>>>>>>> interesting question.) >>>>>>>>>>>>> Now if an always-on AS is required, that is possible, but >>>>>>>>>>>>> probably beyond the scope of this effort and would require so= mething like >>>>>>>>>>>>> an agent-in-the-sky (with diamonds). >>>>>>>>>>>>> here is the link to the 9 min video https://youtu.be >>>>>>>>>>>>> /Tq4hw7X5SW0 >>>>>>>>>>>>> >>>>>>>>>>>>> Peace ..tom >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Ultimately, in most situations like these in the real world, >>>>>>>>>>>>> the hurdle isn=E2=80=99t technical compatibility so much as i= t is trust >>>>>>>>>>>>> compatibility. The RP (client) needs to have some incentive t= o trust the >>>>>>>>>>>>> assertions and identity information that=E2=80=99s coming fro= m the AS. The same is >>>>>>>>>>>>> true for an RS trusting tokens from the AS. The hard question= is less =E2=80=9Chow=E2=80=9D >>>>>>>>>>>>> to do that (which SSI answers), but more =E2=80=9Cwhy=E2=80= =9D to do that (which SSI >>>>>>>>>>>>> doesn=E2=80=99t answer very well, because it=E2=80=99s a hard= question). >>>>>>>>>>>>> >>>>>>>>>>>>> Still: it=E2=80=99s definitely a question about how to suppor= t this >>>>>>>>>>>>> =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the= start of it more than OAuth2/OIDC >>>>>>>>>>>>> have by allowing the bootstrap of the process from a starting= call: the >>>>>>>>>>>>> interaction and continuation URIs handed back by the AS don= =E2=80=99t need to be >>>>>>>>>>>>> the same URIs that the client starts with, so just like SIOP = the process >>>>>>>>>>>>> can start in HTTP and potentially move to other communication= channels. A >>>>>>>>>>>>> major difference is that we aren=E2=80=99t dependent on the a= ssumption that the >>>>>>>>>>>>> user will always be in a browser at some stage, and so the wh= ole raft of >>>>>>>>>>>>> front-channel messages that SIOP relies on doesn=E2=80=99t fl= y. That said, we=E2=80=99ve >>>>>>>>>>>>> got an opportunity to more explicitly open up alternative com= munication >>>>>>>>>>>>> channels here, and that=E2=80=99s something I=E2=80=99d like = to see engineered, even if >>>>>>>>>>>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete= proposal as to how that would >>>>>>>>>>>>> work over specific protocols, starting with what we=E2=80=99v= e got today. >>>>>>>>>>>>> >>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>> >>>>>>>>>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault < >>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Denis, hi Francis, >>>>>>>>>>>>> >>>>>>>>>>>>> At some point integration with SSI (on the authentication >>>>>>>>>>>>> side) will probably occur, including amongst other possibilit= ies SIOP >>>>>>>>>>>>> (since they work with OpenID a part of the work will probably= be made >>>>>>>>>>>>> easier). >>>>>>>>>>>>> >>>>>>>>>>>>> That being said, Denis is right. It's not an AS. Technically >>>>>>>>>>>>> it's entirely possible to rely on a decentralized wallet (for= instance on >>>>>>>>>>>>> your phone) and a centralized AS. I know of a few studies on = how to >>>>>>>>>>>>> decentralize the AS itself (for instance >>>>>>>>>>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralize= d-02 >>>>>>>>>>>>> ). >>>>>>>>>>>>> Maybe it exists, but I'm still looking for real scenarios (or >>>>>>>>>>>>> even architectures) where an AS is deployed directly on a pho= ne, and under >>>>>>>>>>>>> the sole authority of the RO, while being compatible with the= rest of the >>>>>>>>>>>>> world. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Fabien >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hello Francis, >>>>>>>>>>>>> >>>>>>>>>>>>> See two comments in line. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> B) Current Document >>>>>>>>>>>>> >>>>>>>>>>>>> Roles description shall not hold any assumption on the >>>>>>>>>>>>> physical structure of the party fulfilling the roles. >>>>>>>>>>>>> [FI] not sure what you mean >>>>>>>>>>>>> >>>>>>>>>>>>> [FP] for example, we assume the AS is a server! In most SSI >>>>>>>>>>>>> based use cases, the AS will be running on the user device. S= ee SIOP ( >>>>>>>>>>>>> https://identity.foundation/did-siop/). >>>>>>>>>>>>> >>>>>>>>>>>>> I browsed through the two drafts, i.e. : >>>>>>>>>>>>> >>>>>>>>>>>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, >>>>>>>>>>>>> data model, and representations W3C Working Draft 08 Novem= ber 2020 >>>>>>>>>>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. >>>>>>>>>>>>> DIF Working Group Draft >>>>>>>>>>>>> >>>>>>>>>>>>> At no place within these two documents, it is possible to >>>>>>>>>>>>> imagine that "the AS will be running on the user device". >>>>>>>>>>>>> >>>>>>>>>>>>> From section 3 of the DIF Working Group Draft: >>>>>>>>>>>>> >>>>>>>>>>>>> "Unlike the OIDC Authorization Code Flow as per >>>>>>>>>>>>> [OIDC.Core], the SIOP will not return an access token to the = RP". >>>>>>>>>>>>> >>>>>>>>>>>>> An Identity Wallet is not an AS. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Roles: >>>>>>>>>>>>> -> grant endpoint of the AS: Why is this a post request? This >>>>>>>>>>>>> eliminates the chance of having user device hosted AS (no ser= ver). >>>>>>>>>>>>> [FI] what would you propose instead? >>>>>>>>>>>>> Would also be interested to understand better the deployment >>>>>>>>>>>>> model when there is no server. That's something that was disc= ussed several >>>>>>>>>>>>> times but I'm still missing the underlying architecture and u= se case. >>>>>>>>>>>>> >>>>>>>>>>>>> [FP] See above (SIOP). There will be a lot of identity >>>>>>>>>>>>> wallets operated on end user device. >>>>>>>>>>>>> >>>>>>>>>>>>> See the above comment. Please, do not confuse an Identity >>>>>>>>>>>>> Wallet with an Authentication Server (AS). >>>>>>>>>>>>> >>>>>>>>>>>>> Denis >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it >>>>>>>>>>>>> authorize the request or the access to a resource? >>>>>>>>>>>>> [FI] yes, we should make the wording clearer >>>>>>>>>>>>> >>>>>>>>>>>>> Missing Section Interactions: >>>>>>>>>>>>> --> This section shall introduce the notion of interaction >>>>>>>>>>>>> before we start listing interaction types. >>>>>>>>>>>>> [FI] yes >>>>>>>>>>>>> >>>>>>>>>>>>> Interaction Types: >>>>>>>>>>>>> --> I prefer a classification with Redirect, Decoupled and >>>>>>>>>>>>> Embedded is. In the draft, we have one redirect and 2 decoupl= e interactions >>>>>>>>>>>>> and nothing else. >>>>>>>>>>>>> [FI] this should be handled as a specific discussion item. As >>>>>>>>>>>>> a reminder, how would you define embedded? >>>>>>>>>>>>> >>>>>>>>>>>>> In practice there's at least these modes: >>>>>>>>>>>>> - redirect and redirect back >>>>>>>>>>>>> - redirect to different browser or device >>>>>>>>>>>>> - user code >>>>>>>>>>>>> - CIBA >>>>>>>>>>>>> >>>>>>>>>>>>> [FP] This classification is limited. >>>>>>>>>>>>> >>>>>>>>>>>>> - Redirect: same device, same or different user agents >>>>>>>>>>>>> (browser, mobile app, desktop app, ...) >>>>>>>>>>>>> - Decoupled: different devices >>>>>>>>>>>>> - Embedded : RC carries RO authorization to AS >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Resource Access Request vs. Resource Request >>>>>>>>>>>>> --> Both are mixed up. No clarification of the context of eac= h >>>>>>>>>>>>> section. >>>>>>>>>>>>> [FI] could you clarify what you'd expect. Btw on this topic, >>>>>>>>>>>>> there's a more general discussion on whether we should make a= distinction >>>>>>>>>>>>> or not. >>>>>>>>>>>>> >>>>>>>>>>>>> [FP]: Here: >>>>>>>>>>>>> >>>>>>>>>>>>> - Resource Access Request: Requesting Access to a >>>>>>>>>>>>> resource. Response is an access token (or any type of gran= t) >>>>>>>>>>>>> - Resource Request: Request the resource. Response is the >>>>>>>>>>>>> resource (or a corresponding execution) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Token Content Negotiation >>>>>>>>>>>>> --> Not expressed as such. This is central to GNAP and not >>>>>>>>>>>>> represented enough in the document. >>>>>>>>>>>>> [FI] right. This should be a specific discussion item. >>>>>>>>>>>>> >>>>>>>>>>>>> Requesting "User" Information >>>>>>>>>>>>> we identify two types of users: RQ and RO. It will be better >>>>>>>>>>>>> not to refer to a user in this draft, but either to a RQ or a= n RO. >>>>>>>>>>>>> [FI] yes that would avoid potential misunderstandings. >>>>>>>>>>>>> Although in the end, people will translate RQ into user or en= d-user most of >>>>>>>>>>>>> the time. Cf in definition, currently we have Requesting >>>>>>>>>>>>> Party (RQ, aka "user") >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Interaction Again >>>>>>>>>>>>> -> For each interaction type, we will have to describe the >>>>>>>>>>>>> protocol flow and the nature and behavior of involved Roles (= Parties), >>>>>>>>>>>>> Elements, Requests. >>>>>>>>>>>>> [FI] yes >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> [FP] Will these and into tickets? >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards. >>>>>>>>>>>>> /Francis >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> >>> --000000000000842bf805ba988b99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you mean can GNAP work on old fashioned apps runni= ng with existing browsers and existing identity providers, then yes, i gues= s you are ok.

If you want to work on apps where th= e user is in control of authn and authz, then no, GNAP cannot work. It is n= ot alone in that OIDC wont work there either.

Be the change you want to see in the world ..tom


On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault= <fabien.imbault@gmail.com> wrote:
Hi Tom,=C2=A0

Thanks, your responses made it cle= arer for me what you expect from an AS deployed on a mobile.=C2=A0

I think we're on the right p= ath to meet the rest of your concerns. There are already a few items on the= se:
- privacy preserving techniques have been discus= sed and are likely to be included (I think). It's been recognized as a = core concern=C2=A0
- not exactly sure the meaning yo= u give to discovery here (it's already been used in the WG but with a d= ifferent meaning I believe). The request or the continuation api provide en= try points to pay attention to.=C2=A0

Is that enough for your use case ? Do you need something else ? (like SSE?= )


Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, = Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit=C2=A0:
discovery is = the prime problem.=C2=A0 What causes the wallet/AS to wake up and pay atten= tion. How does the RP know what to ask for without violating user privacy r= ights?

CHAPI would be ok i guess, but that requires cred= man to be fixed. Not sure if it fixes discovery or privacy even then.
<= div>
Be the change you w= ant to see in the world ..tom


On Thu, Feb 4, 2021 at 12:45 PM Justin Richer <jricher@mit.edu> wrote:
Tom, what additi= onal functionality do you see that a browser would need to support in order= for GNAP to be adopted? For the elements of the core protocol today, nothi= ng is needed to change within the browsers =E2=80=94 everything is built on= existing functions. GNAP uses browsers as a tool, and I would argue depend= s on them even less so than OAuth 2 does. Extensions could use browser func= tionality, like using CHAPI to pass interaction elements, but the core prot= ocol functions on vanilla browsers today.

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

On Feb 4, 2021, at 3:= 20 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

=
i assumed that the wallet (aka AS) needed to be a nat= ive app, not a PWA (which can come from a traditional web server).
Ther= e are folks, lke Kim C, who are working on a PWA, but i agree the blocks th= ere seem to be large.
THe blocks on a native app are simple, easy= to describe, and easy to ask the browser guys to fix. Not sure if they car= e tho.
I have trouble seeing a path to GNAP adoption for retail c= ustomers w/o some browser support.
That's why i am mostly=C2= =A0silent here.

Be the change you = want to see in the world ..tom


On T= hu, Feb 4, 2021 at 11:43 AM Fabien Imbault <fabien.imbault@gmail.com>= ; wrote:
Fair enough. But loopback limits a lot what you can do... Just f= or debug it's a pain.=C2=A0
But as soon as you try mor= e, it's a bit crazy. Fun to test ipv6 (luckily supported by my ISP) and= ddns. But it feels really hacky.=C2=A0
Also deploym= ent is a pain, compared to a traditional webserver.=C2=A0

Le jeu. 4 f= =C3=A9vr. 2021 =C3=A0 20:20, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit=C2=A0:
does= n't work very well on windows uwp. works fine on smartphones
Be the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:18 AM Jus= tin Richer <jricher@mit.edu> wrote:
OK, thanks =E2=80=94 in that case, there are no changes at all to GNAP, = which is already HTTP driven. The harder parts tend to be where you can=E2= =80=99t (or don=E2=80=99t want to) use something like that.

<= div>=C2=A0=E2=80=94 Justin


yes, loopback

B= e the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:01 AM Justin Richer <jricher@mit.edu> wrote:
Tom, can you expand on h= ow exactly the back-channel =C2=A0communication works between on-device com= ponents? Do you use HTTP locally?

Thanks,
=C2= =A0=E2=80=94 Justin

On Feb 4, 20= 21, at 1:03 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

Justin's analysis of use of the front channel is misleading= .
It could equally be argued that what i have done is installed an AS o= n the phone and the communications with it & the PR is back channel.
Basically the point is that the old OIDC paradigms are no longer va= lid.
Be the change you want to see in the worl= d ..tom


On Thu, Feb 4, 2021 at 7:47= AM Fabien Imbault <= fabien.imbault@gmail.com> wrote:
Yes, issue (#168)=C2=A0message bas= ed interaction / DIDComm is a tentative alternative mecanism for the intera= ction part. Not sure how that would work in details=C2=A0though, prototypin= g will probably help here.
Token delivery=C2=A0through continuation see= ms fine to me. The client will probably have to wait for the next polling b= efore it receives a token issued as the result of an asynchronous interacti= on, but that's not a big issue.

But the AS on = the phone seems like a harder nut to crack, at least at first sight. I thin= k that would be awesome, but it gives me headaches, so I think I'll wor= k on easier stuff right now ;-)

Fabien=C2=A0=C2=A0=

On Thu, Feb 4, 2021 at 4:30 PM Justin Richer <jricher@mit.edu> wrote:
One of the biggest drawbacks= of the current app-centric approaches in OIDC (self-issued OP, or SIOP) is= that they depend on using the front channel and browser redirects to pass = everything, which is something that GNAP is deliberately getting away from = by starting in the back channel.

That said, once a reque= st is kicked off in GNAP, the interaction and fulfillment can happen throug= h any number of means. Part of the work that=E2=80=99s being done with the = =E2=80=9Cinteraction=E2=80=9D section is going to help facilitate this, and= I think that there are some other potential branches here.

<= /div>
Token delivery is where things get extra weird though =E2=80=94 w= e are explicitly not delivering tokens in the front channel in the core of = GNAP, we=E2=80=99re using the response from the continuation API. One idea = (that isn=E2=80=99t particularly well thought out and hasn=E2=80=99t been i= mplemented at all) is to have an extension declare an alternative response = from the =E2=80=9Ccontinue=E2=80=9D section that=E2=80=99s defined today, w= hich points to the GNPA continuation API. If an extension defines some alte= rnative way to deliver tokens, that could live alongside a continuation API= and the client could indicate support for it in its initial request.
=

In any event, alternative interaction and delivery meth= ods are important, and even if we aren=E2=80=99t going to support every las= t one of them directly, the protocol design should at least be aware of the= m.

=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 8:35 AM, Fabien Imbault <fabien.imbault@gmail.com&g= t; wrote:

Hi Tom,=C2=A0

S= ure, any experience on that would be greatly appreciated, we're calling= for help here (the point being that I suspect what they're doing is no= t trivial).

Fabien

On Thu, Feb 4, 2021 at 2:2= 1 PM Tom Jones <= thomasclinganjones@gmail.com> wrote:
I've had such an app work= ing for over a year. There are issues which are being addressed by the brow= ser Interaction team of oidc.

thx ..Tom (mobile)
On Thu, F= eb 4, 2021, 3:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,=C2=A0<= div>
I've tried a few things with regards to using the AS= on a phone, but it's really quite=C2=A0complex.=C2=A0

Making that run on a phone comes with quite a bit of trouble. The = most difficult part if that we'd need to use a secure element, but just= installing and hosting a http server securely is not a standard setup at a= ll. I suggest interested people step in to work on this, as we already have= a lot of work for the (more usual) server case and already handle a privac= y preserving scheme.=C2=A0

Please let us know what= you think.

Cheers,
Fabien=C2=A0

On= Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault <fabien.imbault@gmail.com> wrote= :
Hi Francis,

I've = thought a bit more to what you said. I think I'll give it a try as a se= parate experiment (in code, not in theory). Not that I would expect it to b= e included in GNAP, but I kind of like the idea :-)
=
The direct impact for GNAP would be to think ab= out multiple ASs.=C2=A0

= Will let you know.=C2=A0

Fabien=C2=A0


Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha <fpo@adorsys.de> a= =C3=A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"gmail-m_4891442230495737020m_-8218552788289986907m_-8518815978092546954= m_3550419800836567560m_-8251187544229342067m_6649396458130137896m_330880308= 9207789488m_-435436554859614529m_2888166142485750597gmail-m_790139426681600= 5280gmail-m_-6718184999452512077m_-3004232231493229381m_-886255095867453130= 6m_4552653984562635461m_387929924441527190m_6662104191003806385gmail-m_-542= 839070341023388gmail-m_-6176056956474019294gmail-m_-3037161202240578685gmai= l-m_-7520389457378808664gmail-m_-3342024782330569254m_8014700032835912204gm= ail-m_142651873244800559m_8348797445460806175LPlnk338391" rel=3D"noreferrer= noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferr= er noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" targe= t=3D"_blank">https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>; Dick Hardt <dick.hardt@gmail.com&= gt;; Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@f= ree.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@adorsys.de<= /a>> wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-bounces@ietf.org> on= behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.iet= f@free.fr>; GNAP Mailing List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomascl= inganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail= .com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomascli= nganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin


Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https= ://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr&= gt; wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/= ).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= [FP]: Her= e:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TX= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--000000000000842bf805ba988b99-- From nobody Fri Feb 5 07:56:30 2021 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 DA69E3A12A5 for ; Fri, 5 Feb 2021 07:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 mM5d8TAZsxEl for ; Fri, 5 Feb 2021 07:56:24 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 4A76C3A12A4 for ; Fri, 5 Feb 2021 07:56:24 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id f8so7583043ion.4 for ; Fri, 05 Feb 2021 07:56:24 -0800 (PST) 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=kW8S0dNi8g2Labtvjr05sgtDaoxNgD1siwN7km/AjPs=; b=KUipdqTZx174UbnwTJgNMfQ7sswMMGxJ7fqOiUb7xthzeEAZfshrtuHv6D8CNjacBc TeabBw2J2ruM643yIqtie8tfY9C+b/EFZSXaxVZv1u8qF98qs6SIstLAdzGxLyHRKox5 OIBfAAU8puJAk424Kbmkw7GzZC+R7MvhVgyW9EsWOKIlmriSIOqlXD07RUYHMeZa3S6h lSVZnoJhLiWGgTiMMqGGV4yaURLKVUeTA3d5OoP+4HP1FYeC4ZnFAfniVb2pis1TWLcd SsgmI/5Cib+VOEnyHLBtjU+S+CLG8cgDD+/DbWUTU5dsJV9DQwBhZr+qXmiJlfgRVPeY C53w== 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=kW8S0dNi8g2Labtvjr05sgtDaoxNgD1siwN7km/AjPs=; b=Fy0paN8wDrBhXs4PPvFPZuCbohsZkldrLbYkz/BWvbIBlfpCH4jOfYNU1nnyQkA+N9 srKxpxuYtKfMjRO/+IMPCJXAn2bNsgm7tqlEsQosa/M1VVRRfOhEn0TH+v4X4EmBS+zm Q8WOluQfU4tct0HgQ6aIKCOy9n6DicRJh3zXGcd8WCfyU+tEz7EOQhIr17/aPKjbyVcF /DfimS0f7cXQrjSUMd/JpBXL3oFz14Z4lR3ctfTUB4mzc5gYjf1ZpnD0wBg4Aw4HSm0x BCedM9XOcwAQc0GmMDsxtAYqw859V9Qhwb9IWN5uVBVisQjXAqg02HoCrrEuuaOXPr88 aptA== X-Gm-Message-State: AOAM5301yvHt1EjThh81Ey28FaKGgVVYr4VV26Utmv34Kutxk8XquC4R sKEchM6RJ6y/dZf3d4NvQWAND9Xl8ezHwP5qbgSsl1WRtSDNwA== X-Google-Smtp-Source: ABdhPJxZ2wt22KrWuYmW91nKr9Jh/TAjhe7PPMJTVAnsAkhHUqmTFD3a4TZleT3JuM4WKXIpmIImwGI7bH+ekgQnqqQ= X-Received: by 2002:a02:93a2:: with SMTP id z31mr5652400jah.47.1612540582488; Fri, 05 Feb 2021 07:56:22 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> <77D1AE7B-076F-4095-8FAA-7C35D74614BD@mit.edu> In-Reply-To: From: Fabien Imbault Date: Fri, 5 Feb 2021 16:56:07 +0100 Message-ID: To: Tom Jones Cc: Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="0000000000009aeef305ba98dcd0" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 15:56:29 -0000 --0000000000009aeef305ba98dcd0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Targeting existing browsers and types of applications (web, pwa, mobile, etc.) seems like a reasonable option for an industrial standard. Improving security, privacy, ease of use and interoperability (including decentralized identity as well) should be good enough objectives. Plus from our previous discussions, I was under the impression you were fine with the approach of deploying the AS on the phone as a loopback, for mobile apps. Did I miss something? Cheers, Fabien Le ven. 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones a =C3=A9crit : > If you mean can GNAP work on old fashioned apps running with existing > browsers and existing identity providers, then yes, i guess you are ok. > > If you want to work on apps where the user is in control of authn and > authz, then no, GNAP cannot work. It is not alone in that OIDC wont work > there either. > > Be the change you want to see in the world ..tom > > > On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault > wrote: > >> Hi Tom, >> >> Thanks, your responses made it clearer for me what you expect from an AS >> deployed on a mobile. >> >> I think we're on the right path to meet the rest of your concerns. There >> are already a few items on these: >> - privacy preserving techniques have been discussed and are likely to be >> included (I think). It's been recognized as a core concern >> - not exactly sure the meaning you give to discovery here (it's already >> been used in the WG but with a different meaning I believe). The request= or >> the continuation api provide entry points to pay attention to. >> >> Is that enough for your use case ? Do you need something else ? (like >> SSE?) >> >> Cheers >> Fabien >> >> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom Jones a >> =C3=A9crit : >> >>> discovery is the prime problem. What causes the wallet/AS to wake up >>> and pay attention. How does the RP know what to ask for without violati= ng >>> user privacy rights? >>> >>> CHAPI would be ok i guess, but that requires cred man to be fixed. Not >>> sure if it fixes discovery or privacy even then. >>> >>> Be the change you want to see in the world ..tom >>> >>> >>> On Thu, Feb 4, 2021 at 12:45 PM Justin Richer wrote: >>> >>>> Tom, what additional functionality do you see that a browser would nee= d >>>> to support in order for GNAP to be adopted? For the elements of the co= re >>>> protocol today, nothing is needed to change within the browsers =E2=80= =94 >>>> everything is built on existing functions. GNAP uses browsers as a too= l, >>>> and I would argue depends on them even less so than OAuth 2 does. >>>> Extensions could use browser functionality, like using CHAPI to pass >>>> interaction elements, but the core protocol functions on vanilla brows= ers >>>> today. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Feb 4, 2021, at 3:20 PM, Tom Jones >>>> wrote: >>>> >>>> i assumed that the wallet (aka AS) needed to be a native app, not a PW= A >>>> (which can come from a traditional web server). >>>> There are folks, lke Kim C, who are working on a PWA, but i agree the >>>> blocks there seem to be large. >>>> THe blocks on a native app are simple, easy to describe, and easy to >>>> ask the browser guys to fix. Not sure if they care tho. >>>> I have trouble seeing a path to GNAP adoption for retail customers w/o >>>> some browser support. >>>> That's why i am mostly silent here. >>>> >>>> Be the change you want to see in the world ..tom >>>> >>>> >>>> On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Fair enough. But loopback limits a lot what you can do... Just for >>>>> debug it's a pain. >>>>> But as soon as you try more, it's a bit crazy. Fun to test ipv6 >>>>> (luckily supported by my ISP) and ddns. But it feels really hacky. >>>>> Also deployment is a pain, compared to a traditional webserver. >>>>> >>>>> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones >>>>> a =C3=A9crit : >>>>> >>>>>> doesn't work very well on windows uwp. works fine on smartphones >>>>>> Be the change you want to see in the world ..tom >>>>>> >>>>>> >>>>>> On Thu, Feb 4, 2021 at 11:18 AM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> OK, thanks =E2=80=94 in that case, there are no changes at all to G= NAP, >>>>>>> which is already HTTP driven. The harder parts tend to be where you= can=E2=80=99t >>>>>>> (or don=E2=80=99t want to) use something like that. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Feb 4, 2021, at 2:16 PM, Tom Jones >>>>>>> wrote: >>>>>>> >>>>>>> yes, loopback >>>>>>> >>>>>>> Be the change you want to see in the world ..tom >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 4, 2021 at 11:01 AM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> Tom, can you expand on how exactly the back-channel communication >>>>>>>> works between on-device components? Do you use HTTP locally? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> On Feb 4, 2021, at 1:03 PM, Tom Jones >>>>>>>> wrote: >>>>>>>> >>>>>>>> Justin's analysis of use of the front channel is misleading. >>>>>>>> It could equally be argued that what i have done is installed an A= S >>>>>>>> on the phone and the communications with it & the PR is back chann= el. >>>>>>>> Basically the point is that the old OIDC paradigms are no longer >>>>>>>> valid. >>>>>>>> Be the change you want to see in the world ..tom >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Yes, issue (#168) message based interaction / DIDComm is a >>>>>>>>> tentative alternative mecanism for the interaction part. Not sure= how that >>>>>>>>> would work in details though, prototyping will probably help here= . >>>>>>>>> Token delivery through continuation seems fine to me. The client >>>>>>>>> will probably have to wait for the next polling before it receive= s a token >>>>>>>>> issued as the result of an asynchronous interaction, but that's n= ot a big >>>>>>>>> issue. >>>>>>>>> >>>>>>>>> But the AS on the phone seems like a harder nut to crack, at leas= t >>>>>>>>> at first sight. I think that would be awesome, but it gives me he= adaches, >>>>>>>>> so I think I'll work on easier stuff right now ;-) >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> One of the biggest drawbacks of the current app-centric >>>>>>>>>> approaches in OIDC (self-issued OP, or SIOP) is that they depend= on using >>>>>>>>>> the front channel and browser redirects to pass everything, whic= h is >>>>>>>>>> something that GNAP is deliberately getting away from by startin= g in the >>>>>>>>>> back channel. >>>>>>>>>> >>>>>>>>>> That said, once a request is kicked off in GNAP, the interaction >>>>>>>>>> and fulfillment can happen through any number of means. Part of = the work >>>>>>>>>> that=E2=80=99s being done with the =E2=80=9Cinteraction=E2=80=9D= section is going to help >>>>>>>>>> facilitate this, and I think that there are some other potential= branches >>>>>>>>>> here. >>>>>>>>>> >>>>>>>>>> Token delivery is where things get extra weird though =E2=80=94 = we are >>>>>>>>>> explicitly not delivering tokens in the front channel in the cor= e of GNAP, >>>>>>>>>> we=E2=80=99re using the response from the continuation API. One = idea (that isn=E2=80=99t >>>>>>>>>> particularly well thought out and hasn=E2=80=99t been implemente= d at all) is to >>>>>>>>>> have an extension declare an alternative response from the =E2= =80=9Ccontinue=E2=80=9D >>>>>>>>>> section that=E2=80=99s defined today, which points to the GNPA c= ontinuation API. If >>>>>>>>>> an extension defines some alternative way to deliver tokens, tha= t could >>>>>>>>>> live alongside a continuation API and the client could indicate = support for >>>>>>>>>> it in its initial request. >>>>>>>>>> >>>>>>>>>> In any event, alternative interaction and delivery methods are >>>>>>>>>> important, and even if we aren=E2=80=99t going to support every = last one of them >>>>>>>>>> directly, the protocol design should at least be aware of them. >>>>>>>>>> >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>> >>>>>>>>>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> Hi Tom, >>>>>>>>>> >>>>>>>>>> Sure, any experience on that would be greatly appreciated, we're >>>>>>>>>> calling for help here (the point being that I suspect what they'= re doing is >>>>>>>>>> not trivial). >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones < >>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> I've had such an app working for over a year. There are issues >>>>>>>>>>> which are being addressed by the browser Interaction team of oi= dc. >>>>>>>>>>> >>>>>>>>>>> thx ..Tom (mobile) >>>>>>>>>>> >>>>>>>>>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Francis, >>>>>>>>>>>> >>>>>>>>>>>> I've tried a few things with regards to using the AS on a >>>>>>>>>>>> phone, but it's really quite complex. >>>>>>>>>>>> >>>>>>>>>>>> Making that run on a phone comes with quite a bit of trouble. >>>>>>>>>>>> The most difficult part if that we'd need to use a secure elem= ent, but just >>>>>>>>>>>> installing and hosting a http server securely is not a standar= d setup at >>>>>>>>>>>> all. I suggest interested people step in to work on this, as w= e already >>>>>>>>>>>> have a lot of work for the (more usual) server case and alread= y handle a >>>>>>>>>>>> privacy preserving scheme. >>>>>>>>>>>> >>>>>>>>>>>> Please let us know what you think. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Fabien >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault < >>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Francis, >>>>>>>>>>>>> >>>>>>>>>>>>> I've thought a bit more to what you said. I think I'll give i= t >>>>>>>>>>>>> a try as a separate experiment (in code, not in theory). Not = that I would >>>>>>>>>>>>> expect it to be included in GNAP, but I kind of like the idea= :-) >>>>>>>>>>>>> >>>>>>>>>>>>> The direct impact for GNAP would be to think about multiple >>>>>>>>>>>>> ASs. >>>>>>>>>>>>> >>>>>>>>>>>>> Will let you know. >>>>>>>>>>>>> >>>>>>>>>>>>> Fabien >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha >>>>>>>>>>>>> a =C3=A9crit : >>>>>>>>>>>>> >>>>>>>>>>>>>> It would be nice if the protocol was designed at many layers >>>>>>>>>>>>>> of abstraction. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> - The first layer shall design abstract protocol flows, >>>>>>>>>>>>>> without specification of the mode and mechanism of intera= ction. >>>>>>>>>>>>>> - The second layer can instantiate the first layer for >>>>>>>>>>>>>> dedicated interaction. Here we can talk http, we can defi= ne interactions >>>>>>>>>>>>>> that presume server based token generation, we can define= interaction that >>>>>>>>>>>>>> run on user device based token generation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is also the fundament of the structure I proposed for >>>>>>>>>>>>>> the spec ( >>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30 >>>>>>>>>>>>>> ). >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Francis >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>> *From:* Fabien Imbault >>>>>>>>>>>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>>>>>>>>>>>> *To:* Francis Pouatcha >>>>>>>>>>>>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>>>>>>>>>>>> dick.hardt@gmail.com>; Tom Jones < >>>>>>>>>>>>>> thomasclinganjones@gmail.com>; Denis ; >>>>>>>>>>>>>> Justin Richer >>>>>>>>>>>>>> *Subject:* Re: [GNAP] Review of >>>>>>>>>>>>>> draft-ietf-gnap-core-protocol-00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Would make sense, but not so easy as we rely heavily on HTTP= . >>>>>>>>>>>>>> Hence the discussion about deep links and so on. >>>>>>>>>>>>>> >>>>>>>>>>>>>> An alternative might be provided by wasm/wasi (running a >>>>>>>>>>>>>> local sandbox on your phone, for your own AS), but it's real= ly early stage. >>>>>>>>>>>>>> This also poses another question that Denis has put forward,= i.e. how do we >>>>>>>>>>>>>> handle the multiple AS scenario (likely to occur then). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha < >>>>>>>>>>>>>> fpo@adorsys.de> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> We are drifting away from the original problem space. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - My original mention was about the "POST" request, that >>>>>>>>>>>>>> subsumes that the "AS" is a "Server". Designing a new pro= tocol, we cannot >>>>>>>>>>>>>> afford this limitation. >>>>>>>>>>>>>> - I just mentioned SIOP to show a known and closed >>>>>>>>>>>>>> example? Let us not focus on the device local discovery s= cheme (like >>>>>>>>>>>>>> openid:) for now. >>>>>>>>>>>>>> - As capability of holding private keys on user device >>>>>>>>>>>>>> evolves, server-based issuing of token will be fading out= giving way to >>>>>>>>>>>>>> device local generation of token. >>>>>>>>>>>>>> >>>>>>>>>>>>>> While designing GNAP, let us assume the AS-Role can be >>>>>>>>>>>>>> exercised on a user device and design the protocol to honor = that. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> /Francis >>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>> *From:* TXAuth on behalf of Dick >>>>>>>>>>>>>> Hardt >>>>>>>>>>>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>>>>>>>>>>>> *To:* Tom Jones >>>>>>>>>>>>>> *Cc:* Fabien Imbault ; Denis < >>>>>>>>>>>>>> denis.ietf@free.fr>; GNAP Mailing List ; >>>>>>>>>>>>>> Justin Richer >>>>>>>>>>>>>> *Subject:* Re: [GNAP] Review of >>>>>>>>>>>>>> draft-ietf-gnap-core-protocol-00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Got it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So web apps invoke a openid: deep link and hope there is an >>>>>>>>>>>>>> app to handle the openid: scheme? ... and that it is the use= r's wallet >>>>>>>>>>>>>> rather than some malware that has registered openid: on the = mobile device? >>>>>>>>>>>>>> >>>>>>>>>>>>>> A native app can attempt to open a deep link associated with >>>>>>>>>>>>>> an app, and will fail if the app is not there. If the app is= there, it will >>>>>>>>>>>>>> be opened, so this can't be used to silently test if an app = is present, but >>>>>>>>>>>>>> it does allow a native app to provide an alternative experie= nce if an app >>>>>>>>>>>>>> is not present. I don't think this works with custom schemes= ... and I >>>>>>>>>>>>>> don't know how it could work from a web app on the phone wit= h the current >>>>>>>>>>>>>> Safari APIs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Apple warns against using custom schemes [1] ... but perhaps >>>>>>>>>>>>>> they can be convinced to make openid: a managed scheme simil= ar to mailto:, >>>>>>>>>>>>>> tel:, sms:, facetime: ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] >>>>>>>>>>>>>> https://developer.apple.com/documentation/xcode/allowing_app= s_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_you= r_app >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> You are - that is not standard which is opeind:// >>>>>>>>>>>>>> This is the one step that still needs to be optimized for >>>>>>>>>>>>>> SIOP to have good UX. >>>>>>>>>>>>>> Peace ..tom >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt < >>>>>>>>>>>>>> dick.hardt@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Tom >>>>>>>>>>>>>> >>>>>>>>>>>>>> I watched your video (I watched at 2X speed) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Looks like the employment website app that is using >>>>>>>>>>>>>> localhost:8765 to communicate with the wallet. Am I correct? >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Dick >>>>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones < >>>>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Well, here's a demo. Note that in this case the AS is not >>>>>>>>>>>>>> online all of the time, so it is really implicit flow and th= e OIDC id-token >>>>>>>>>>>>>> comes from the siop device directly. >>>>>>>>>>>>>> (whether this is front-channel or back channel is no longer >>>>>>>>>>>>>> an interesting question.) >>>>>>>>>>>>>> Now if an always-on AS is required, that is possible, but >>>>>>>>>>>>>> probably beyond the scope of this effort and would require s= omething like >>>>>>>>>>>>>> an agent-in-the-sky (with diamonds). >>>>>>>>>>>>>> here is the link to the 9 min video https://youtu.be >>>>>>>>>>>>>> /Tq4hw7X5SW0 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Peace ..tom >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer < >>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ultimately, in most situations like these in the real world, >>>>>>>>>>>>>> the hurdle isn=E2=80=99t technical compatibility so much as = it is trust >>>>>>>>>>>>>> compatibility. The RP (client) needs to have some incentive = to trust the >>>>>>>>>>>>>> assertions and identity information that=E2=80=99s coming fr= om the AS. The same is >>>>>>>>>>>>>> true for an RS trusting tokens from the AS. The hard questio= n is less =E2=80=9Chow=E2=80=9D >>>>>>>>>>>>>> to do that (which SSI answers), but more =E2=80=9Cwhy=E2=80= =9D to do that (which SSI >>>>>>>>>>>>>> doesn=E2=80=99t answer very well, because it=E2=80=99s a har= d question). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Still: it=E2=80=99s definitely a question about how to suppo= rt this >>>>>>>>>>>>>> =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got th= e start of it more than OAuth2/OIDC >>>>>>>>>>>>>> have by allowing the bootstrap of the process from a startin= g call: the >>>>>>>>>>>>>> interaction and continuation URIs handed back by the AS don= =E2=80=99t need to be >>>>>>>>>>>>>> the same URIs that the client starts with, so just like SIOP= the process >>>>>>>>>>>>>> can start in HTTP and potentially move to other communicatio= n channels. A >>>>>>>>>>>>>> major difference is that we aren=E2=80=99t dependent on the = assumption that the >>>>>>>>>>>>>> user will always be in a browser at some stage, and so the w= hole raft of >>>>>>>>>>>>>> front-channel messages that SIOP relies on doesn=E2=80=99t f= ly. That said, we=E2=80=99ve >>>>>>>>>>>>>> got an opportunity to more explicitly open up alternative co= mmunication >>>>>>>>>>>>>> channels here, and that=E2=80=99s something I=E2=80=99d like= to see engineered, even if >>>>>>>>>>>>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concret= e proposal as to how that would >>>>>>>>>>>>>> work over specific protocols, starting with what we=E2=80=99= ve got today. >>>>>>>>>>>>>> >>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault < >>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Denis, hi Francis, >>>>>>>>>>>>>> >>>>>>>>>>>>>> At some point integration with SSI (on the authentication >>>>>>>>>>>>>> side) will probably occur, including amongst other possibili= ties SIOP >>>>>>>>>>>>>> (since they work with OpenID a part of the work will probabl= y be made >>>>>>>>>>>>>> easier). >>>>>>>>>>>>>> >>>>>>>>>>>>>> That being said, Denis is right. It's not an AS. Technically >>>>>>>>>>>>>> it's entirely possible to rely on a decentralized wallet (fo= r instance on >>>>>>>>>>>>>> your phone) and a centralized AS. I know of a few studies on= how to >>>>>>>>>>>>>> decentralize the AS itself (for instance >>>>>>>>>>>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentraliz= ed-02 >>>>>>>>>>>>>> ). >>>>>>>>>>>>>> Maybe it exists, but I'm still looking for real scenarios (o= r >>>>>>>>>>>>>> even architectures) where an AS is deployed directly on a ph= one, and under >>>>>>>>>>>>>> the sole authority of the RO, while being compatible with th= e rest of the >>>>>>>>>>>>>> world. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello Francis, >>>>>>>>>>>>>> >>>>>>>>>>>>>> See two comments in line. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> B) Current Document >>>>>>>>>>>>>> >>>>>>>>>>>>>> Roles description shall not hold any assumption on the >>>>>>>>>>>>>> physical structure of the party fulfilling the roles. >>>>>>>>>>>>>> [FI] not sure what you mean >>>>>>>>>>>>>> >>>>>>>>>>>>>> [FP] for example, we assume the AS is a server! In most SSI >>>>>>>>>>>>>> based use cases, the AS will be running on the user device. = See SIOP ( >>>>>>>>>>>>>> https://identity.foundation/did-siop/). >>>>>>>>>>>>>> >>>>>>>>>>>>>> I browsed through the two drafts, i.e. : >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Decentralized Identifiers (DIDs) v1.0 Core >>>>>>>>>>>>>> architecture, data model, and representations W3C Working= Draft 08 November >>>>>>>>>>>>>> 2020 >>>>>>>>>>>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. >>>>>>>>>>>>>> DIF Working Group Draft >>>>>>>>>>>>>> >>>>>>>>>>>>>> At no place within these two documents, it is possible to >>>>>>>>>>>>>> imagine that "the AS will be running on the user device". >>>>>>>>>>>>>> >>>>>>>>>>>>>> From section 3 of the DIF Working Group Draft: >>>>>>>>>>>>>> >>>>>>>>>>>>>> "Unlike the OIDC Authorization Code Flow as per >>>>>>>>>>>>>> [OIDC.Core], the SIOP will not return an access token to the= RP". >>>>>>>>>>>>>> >>>>>>>>>>>>>> An Identity Wallet is not an AS. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Roles: >>>>>>>>>>>>>> -> grant endpoint of the AS: Why is this a post request? Thi= s >>>>>>>>>>>>>> eliminates the chance of having user device hosted AS (no se= rver). >>>>>>>>>>>>>> [FI] what would you propose instead? >>>>>>>>>>>>>> Would also be interested to understand better the deployment >>>>>>>>>>>>>> model when there is no server. That's something that was dis= cussed several >>>>>>>>>>>>>> times but I'm still missing the underlying architecture and = use case. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [FP] See above (SIOP). There will be a lot of identity >>>>>>>>>>>>>> wallets operated on end user device. >>>>>>>>>>>>>> >>>>>>>>>>>>>> See the above comment. Please, do not confuse an Identity >>>>>>>>>>>>>> Wallet with an Authentication Server (AS). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Denis >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it >>>>>>>>>>>>>> authorize the request or the access to a resource? >>>>>>>>>>>>>> [FI] yes, we should make the wording clearer >>>>>>>>>>>>>> >>>>>>>>>>>>>> Missing Section Interactions: >>>>>>>>>>>>>> --> This section shall introduce the notion of interaction >>>>>>>>>>>>>> before we start listing interaction types. >>>>>>>>>>>>>> [FI] yes >>>>>>>>>>>>>> >>>>>>>>>>>>>> Interaction Types: >>>>>>>>>>>>>> --> I prefer a classification with Redirect, Decoupled and >>>>>>>>>>>>>> Embedded is. In the draft, we have one redirect and 2 decoup= le interactions >>>>>>>>>>>>>> and nothing else. >>>>>>>>>>>>>> [FI] this should be handled as a specific discussion item. A= s >>>>>>>>>>>>>> a reminder, how would you define embedded? >>>>>>>>>>>>>> >>>>>>>>>>>>>> In practice there's at least these modes: >>>>>>>>>>>>>> - redirect and redirect back >>>>>>>>>>>>>> - redirect to different browser or device >>>>>>>>>>>>>> - user code >>>>>>>>>>>>>> - CIBA >>>>>>>>>>>>>> >>>>>>>>>>>>>> [FP] This classification is limited. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Redirect: same device, same or different user agents >>>>>>>>>>>>>> (browser, mobile app, desktop app, ...) >>>>>>>>>>>>>> - Decoupled: different devices >>>>>>>>>>>>>> - Embedded : RC carries RO authorization to AS >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Resource Access Request vs. Resource Request >>>>>>>>>>>>>> --> Both are mixed up. No clarification of the context of >>>>>>>>>>>>>> each section. >>>>>>>>>>>>>> [FI] could you clarify what you'd expect. Btw on this topic= , >>>>>>>>>>>>>> there's a more general discussion on whether we should make = a distinction >>>>>>>>>>>>>> or not. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [FP]: Here: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Resource Access Request: Requesting Access to a >>>>>>>>>>>>>> resource. Response is an access token (or any type of gra= nt) >>>>>>>>>>>>>> - Resource Request: Request the resource. Response is the >>>>>>>>>>>>>> resource (or a corresponding execution) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Token Content Negotiation >>>>>>>>>>>>>> --> Not expressed as such. This is central to GNAP and not >>>>>>>>>>>>>> represented enough in the document. >>>>>>>>>>>>>> [FI] right. This should be a specific discussion item. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Requesting "User" Information >>>>>>>>>>>>>> we identify two types of users: RQ and RO. It will be better >>>>>>>>>>>>>> not to refer to a user in this draft, but either to a RQ or = an RO. >>>>>>>>>>>>>> [FI] yes that would avoid potential misunderstandings. >>>>>>>>>>>>>> Although in the end, people will translate RQ into user or e= nd-user most of >>>>>>>>>>>>>> the time. Cf in definition, currently we have Requesting >>>>>>>>>>>>>> Party (RQ, aka "user") >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Interaction Again >>>>>>>>>>>>>> -> For each interaction type, we will have to describe the >>>>>>>>>>>>>> protocol flow and the nature and behavior of involved Roles = (Parties), >>>>>>>>>>>>>> Elements, Requests. >>>>>>>>>>>>>> [FI] yes >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> [FP] Will these and into tickets? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards. >>>>>>>>>>>>>> /Francis >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> >>>> --0000000000009aeef305ba98dcd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Targeting existing browsers and typ= es of applications (web, pwa, mobile, etc.) seems like a reasonable option = for an industrial standard. Improving security, privacy, ease of use and in= teroperability (including decentralized identity as well) should be good en= ough objectives.=C2=A0
Plus from our previous discussions, I was = under the impression you were fine with the approach of deploying the AS on= the phone as a loopback, for mobile apps. Did I miss something?

Cheers,
Fabien

Le ven. 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones <thomasclinganjones@gmail.com<= /a>> a =C3=A9crit=C2=A0:



On = Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault <fabien.imbault@gmail.c= om> wrote:
Hi Tom,=C2=A0
<= div dir=3D"auto">
Thanks, your responses made it= clearer for me what you expect from an AS deployed on a mobile.=C2=A0

I think we're on the rig= ht path to meet the rest of your concerns. There are already a few items on= these:
- privacy preserving techniques have been di= scussed and are likely to be included (I think). It's been recognized a= s a core concern=C2=A0
- not exactly sure the meanin= g you give to discovery here (it's already been used in the WG but with= a different meaning I believe). The request or the continuation api provid= e entry points to pay attention to.=C2=A0

=
Is that enough for your use case ? Do you need something else ? (like = SSE?)

Cheers
Fabien=C2=A0

<= div dir=3D"ltr" class=3D"gmail_attr">Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10= , Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit=C2=A0:
= discovery is the prime problem.=C2=A0 What causes the wallet/AS to wake up = and pay attention. How does the RP know what to ask for without violating u= ser privacy rights?

CHAPI would be ok i guess, but that = requires cred man to be fixed. Not sure if it fixes discovery or privacy ev= en then.

<= div>Be the= change you want to see in the world ..tom

On Thu, Feb 4, 2021 at 12:45 PM Justin Richer <jricher@= mit.edu> wrote:
Tom, what additional functionality do you see that a browser wo= uld need to support in order for GNAP to be adopted? For the elements of th= e core protocol today, nothing is needed to change within the browsers =E2= =80=94 everything is built on existing functions. GNAP uses browsers as a t= ool, and I would argue depends on them even less so than OAuth 2 does. Exte= nsions could use browser functionality, like using CHAPI to pass interactio= n elements, but the core protocol functions on vanilla browsers today.
=
=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 3:20 PM, Tom Jones <thomasclinganjo= nes@gmail.com> wrote:

i assumed that = the wallet (aka AS) needed to be a native app, not a PWA (which can come fr= om a traditional web server).
There are folks, lke Kim C, who are worki= ng on a PWA, but i agree the blocks there seem to be large.
THe b= locks on a native app are simple, easy to describe, and easy to ask the bro= wser guys to fix. Not sure if they care tho.
I have trouble seein= g a path to GNAP adoption for retail customers w/o some browser support.
That's why i am mostly=C2=A0silent here.

Be the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:43 AM Fabien Imba= ult <fabien.imbault@gmail.com> wrote:
Fair enough. But = loopback limits a lot what you can do... Just for debug it's a pain.=C2= =A0
But as soon as you try more, it's a bit crazy. Fun= to test ipv6 (luckily supported by my ISP) and ddns. But it feels really h= acky.=C2=A0
Also deployment is a pain, compared to a= traditional webserver.=C2=A0

Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, = Tom Jones <thoma= sclinganjones@gmail.com> a =C3=A9crit=C2=A0:
doesn't work very = well on windows uwp. works fine on smartphones
<= div dir=3D"ltr">
Be the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:18 AM Justin Richer <jricher@mit.edu> wr= ote:
OK, th= anks =E2=80=94 in that case, there are no changes at all to GNAP, which is = already HTTP driven. The harder parts tend to be where you can=E2=80=99t (o= r don=E2=80=99t want to) use something like that.

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

On Feb 4, 2021,= at 2:16 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

yes, loopback

= Be the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:01 AM Justin Richer <jricher@mit.edu> wrot= e:
Tom, can= you expand on how exactly the back-channel =C2=A0communication works betwe= en on-device components? Do you use HTTP locally?

Thanks= ,
=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 1:03 PM, Tom Jones <thomasclinganjones@gmail.com> w= rote:

Justin's analysis of use of the fr= ont channel is misleading.
It could equally be argued that what i have = done is installed an AS on the phone and the communications with it & t= he PR is back channel.
Basically the point is that the old OIDC p= aradigms are no longer valid.
Be the change yo= u want to see in the world ..tom


On= Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:=
Yes, issue (#168)=C2=A0message based interaction / DIDComm is a tentative= alternative mecanism for the interaction part. Not sure how that would wor= k in details=C2=A0though, prototyping will probably help here.
Token de= livery=C2=A0through continuation seems fine to me. The client will probably= have to wait for the next polling before it receives a token issued as the= result of an asynchronous interaction, but that's not a big issue.

But the AS on the phone seems like a harder nut to cr= ack, at least at first sight. I think that would be awesome, but it gives m= e headaches, so I think I'll work on easier stuff right now ;-)

Fabien=C2=A0=C2=A0

On Thu, Feb 4, 2021 at 4:30 P= M Justin Richer <j= richer@mit.edu> wrote:
One of the biggest drawbacks of the current app-centric = approaches in OIDC (self-issued OP, or SIOP) is that they depend on using t= he front channel and browser redirects to pass everything, which is somethi= ng that GNAP is deliberately getting away from by starting in the back chan= nel.

That said, once a request is kicked off in GNAP, th= e interaction and fulfillment can happen through any number of means. Part = of the work that=E2=80=99s being done with the =E2=80=9Cinteraction=E2=80= =9D section is going to help facilitate this, and I think that there are so= me other potential branches here.

Token delivery i= s where things get extra weird though =E2=80=94 we are explicitly not deliv= ering tokens in the front channel in the core of GNAP, we=E2=80=99re using = the response from the continuation API. One idea (that isn=E2=80=99t partic= ularly well thought out and hasn=E2=80=99t been implemented at all) is to h= ave an extension declare an alternative response from the =E2=80=9Ccontinue= =E2=80=9D section that=E2=80=99s defined today, which points to the GNPA co= ntinuation API. If an extension defines some alternative way to deliver tok= ens, that could live alongside a continuation API and the client could indi= cate support for it in its initial request.

In any= event, alternative interaction and delivery methods are important, and eve= n if we aren=E2=80=99t going to support every last one of them directly, th= e protocol design should at least be aware of them.

=C2=A0=E2=80=94 Justin

On Feb = 4, 2021, at 8:35 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Tom,=C2=A0

Sure, any experien= ce on that would be greatly appreciated, we're calling for help here (t= he point being that I suspect what they're doing is not trivial).
=

Fabien

On Thu, Feb 4, 2021 at 2:21 PM Tom Jones &l= t;thomas= clinganjones@gmail.com> wrote:
I've had such an app working fo= r over a year. There are issues which are being addressed by the browser In= teraction team of oidc.

thx ..Tom (mobile)

On Thu, Feb 4, = 2021, 3:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,= =C2=A0

I've tried a few things with regards to using= the AS on a phone, but it's really quite=C2=A0complex.=C2=A0

Making that run on a phone comes with quite a bit of troubl= e. The most difficult part if that we'd need to use a secure element, b= ut just installing and hosting a http server securely is not a standard set= up at all. I suggest interested people step in to work on this, as we alrea= dy have a lot of work for the (more usual) server case and already handle a= privacy preserving scheme.=C2=A0

Please let us kn= ow what you think.

Cheers,
Fabien=C2=A0<= /div>

On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault <fabien.imbault@gmail= .com> wrote:
Hi Francis,

I've thought a bit more to what you said. I think I'll gi= ve it a try as a separate experiment (in code, not in theory). Not that I w= ould expect it to be included in GNAP, but I kind of like the idea :-)

The direct impact for GNAP w= ould be to think about multiple ASs.=C2=A0

Will let you know.=C2=A0

Fabien=C2=A0


Le mer. 18 nov. 2020 =C3=A0 13:06, Fran= cis Pouatcha <fpo@adorsys.de> a =C3=A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"m_3740723253088693496m_-99671316316621892gmail-m_4891442230495737020m_-= 8218552788289986907m_-8518815978092546954m_3550419800836567560m_-8251187544= 229342067m_6649396458130137896m_3308803089207789488m_-435436554859614529m_2= 888166142485750597gmail-m_7901394266816005280gmail-m_-6718184999452512077m_= -3004232231493229381m_-8862550958674531306m_4552653984562635461m_3879299244= 41527190m_6662104191003806385gmail-m_-542839070341023388gmail-m_-6176056956= 474019294gmail-m_-3037161202240578685gmail-m_-7520389457378808664gmail-m_-3= 342024782330569254m_8014700032835912204gmail-m_142651873244800559m_83487974= 45460806175LPlnk338391" rel=3D"noreferrer noreferrer noreferrer noreferrer = noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferre= r noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">https://gi= thub.com/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <fab= ien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>; Dick Hardt &= lt;dick.hardt@gmail.com>; Tom Jones <thomascl= inganjones@gmail.com>; Denis <denis.ietf@free.fr>; Jus= tin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@= adorsys.de> wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
= From: TX= Auth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>=
Cc: Fabien Imbault <fabien.imbault@gmail.com>; D= enis <denis.ietf@free.fr>; GNAP Mailing List <txauth@ietf= .org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.= hardt@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jriche= r@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imba= ult@gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02= ).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@f= ree.fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-= siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= [FP]: Her= e:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txa= uth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txa= uth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txa= uth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txau= th


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--0000000000009aeef305ba98dcd0-- From nobody Fri Feb 5 09:55:49 2021 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 17F453A0DF0 for ; Fri, 5 Feb 2021 09:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 NzQRhxancR7n for ; Fri, 5 Feb 2021 09:55:38 -0800 (PST) Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (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 4A57D3A0E10 for ; Fri, 5 Feb 2021 09:55:38 -0800 (PST) Received: by mail-oo1-xc32.google.com with SMTP id x10so298719oor.3 for ; Fri, 05 Feb 2021 09:55:38 -0800 (PST) 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=b1YsWVfobys7xLHI5qSrBcnZVrUFYOjqwy+KF9QMN+U=; b=f1qap04FW/aKOzpe/y5urEmvkMgGjEM0xfNX6ChwWCIRUr3ekb8tNSmGSmnBAqwWmS CQQ13VoySlEVfA6lmZ0qWHVuGmeYqlYNHoPipzGf4/q+B5fZ0ilyt9IaR49vRTbASv4J 8Elc+R1B1Kvb8y6Dsi6CyPuC50uIriKWXgjmxBMO08sqh7o8CLDOwj/HE+c2+Gc9BMu4 elJ5nY0ZiQzSTjAJGJVTojVaijZZ1XkMh9C2mbVZxlMKG7izL6ivRD14Ij0pjhLDb/4E UD/ROQhrw1kvz+/mHAKQy0sTFgoyejaBnYDLV6fscxOTlJ6MIIYXj4anwwKPBr85e59L 8flA== 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=b1YsWVfobys7xLHI5qSrBcnZVrUFYOjqwy+KF9QMN+U=; b=PC0btgXqCYwYKlkb5r/6+gdghaEINoTmU2am1SfbbXj8gn9ssn+TiWPDTMQg7KGAP8 v7zNO+aGtT9h8z5rDz/XHArCyk0HIDjUlw7lNo0is7m0/wcwWgna0OOSspQ/0Lon9v3C N5liA2arTooPkI7yxNCQOGjNKyrYLD0+SGhQQU9Cq+elcj6CuE+3JBEm5beTNIsNw88u JKb+E1mlkFnrELtx9gHv3kgLAUHcA7+UhespUWrGQ9VuIBu8yitEwCYvDgoedslD62su 1kiSV1mXBdxRDZUjLD2Qz/Ys2WHvJzP6PUrMhpI3b7uYtWjIciti7JjUpEPy3pbRiRM+ FZ+A== X-Gm-Message-State: AOAM531pVi10t3bpIW1rMehtUMzw8HNvFS/TIY0PWO+dPH7QcWfU6Y1j 0GL5EFE6GCVW2K7Wf/TD6ZZz18aeybdTwaPBStk= X-Google-Smtp-Source: ABdhPJySvRDQ7g5kzBs2H/p2IDX6CXXD90TG0YDgAzFAzt0MCix9MWj5G04L7lVydpFf6XbFUHzaKeAVb0tlcKCrCNY= X-Received: by 2002:a4a:8555:: with SMTP id l21mr4348113ooh.27.1612547737410; Fri, 05 Feb 2021 09:55:37 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> <77D1AE7B-076F-4095-8FAA-7C35D74614BD@mit.edu> In-Reply-To: From: Tom Jones Date: Fri, 5 Feb 2021 09:55:24 -0800 Message-ID: To: Fabien Imbault Cc: Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="000000000000125ef505ba9a8782" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 17:55:47 -0000 --000000000000125ef505ba9a8782 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No, you didn't misunderstand me. It's just that the ux for that is not acceptable to retail users. As long as gnap sticks to industrial users you should do fine. thx ..Tom (mobile) On Fri, Feb 5, 2021, 7:56 AM Fabien Imbault wrote: > Targeting existing browsers and types of applications (web, pwa, mobile, > etc.) seems like a reasonable option for an industrial standard. Improvin= g > security, privacy, ease of use and interoperability (including > decentralized identity as well) should be good enough objectives. > Plus from our previous discussions, I was under the impression you were > fine with the approach of deploying the AS on the phone as a loopback, fo= r > mobile apps. Did I miss something? > > Cheers, > Fabien > > Le ven. 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones a > =C3=A9crit : > >> If you mean can GNAP work on old fashioned apps running with existing >> browsers and existing identity providers, then yes, i guess you are ok. >> >> If you want to work on apps where the user is in control of authn and >> authz, then no, GNAP cannot work. It is not alone in that OIDC wont work >> there either. >> >> Be the change you want to see in the world ..tom >> >> >> On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault >> wrote: >> >>> Hi Tom, >>> >>> Thanks, your responses made it clearer for me what you expect from an A= S >>> deployed on a mobile. >>> >>> I think we're on the right path to meet the rest of your concerns. Ther= e >>> are already a few items on these: >>> - privacy preserving techniques have been discussed and are likely to b= e >>> included (I think). It's been recognized as a core concern >>> - not exactly sure the meaning you give to discovery here (it's already >>> been used in the WG but with a different meaning I believe). The reques= t or >>> the continuation api provide entry points to pay attention to. >>> >>> Is that enough for your use case ? Do you need something else ? (like >>> SSE?) >>> >>> Cheers >>> Fabien >>> >>> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom Jones >>> a =C3=A9crit : >>> >>>> discovery is the prime problem. What causes the wallet/AS to wake up >>>> and pay attention. How does the RP know what to ask for without violat= ing >>>> user privacy rights? >>>> >>>> CHAPI would be ok i guess, but that requires cred man to be fixed. Not >>>> sure if it fixes discovery or privacy even then. >>>> >>>> Be the change you want to see in the world ..tom >>>> >>>> >>>> On Thu, Feb 4, 2021 at 12:45 PM Justin Richer wrote: >>>> >>>>> Tom, what additional functionality do you see that a browser would >>>>> need to support in order for GNAP to be adopted? For the elements of = the >>>>> core protocol today, nothing is needed to change within the browsers = =E2=80=94 >>>>> everything is built on existing functions. GNAP uses browsers as a to= ol, >>>>> and I would argue depends on them even less so than OAuth 2 does. >>>>> Extensions could use browser functionality, like using CHAPI to pass >>>>> interaction elements, but the core protocol functions on vanilla brow= sers >>>>> today. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Feb 4, 2021, at 3:20 PM, Tom Jones >>>>> wrote: >>>>> >>>>> i assumed that the wallet (aka AS) needed to be a native app, not a >>>>> PWA (which can come from a traditional web server). >>>>> There are folks, lke Kim C, who are working on a PWA, but i agree the >>>>> blocks there seem to be large. >>>>> THe blocks on a native app are simple, easy to describe, and easy to >>>>> ask the browser guys to fix. Not sure if they care tho. >>>>> I have trouble seeing a path to GNAP adoption for retail customers w/= o >>>>> some browser support. >>>>> That's why i am mostly silent here. >>>>> >>>>> Be the change you want to see in the world ..tom >>>>> >>>>> >>>>> On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Fair enough. But loopback limits a lot what you can do... Just for >>>>>> debug it's a pain. >>>>>> But as soon as you try more, it's a bit crazy. Fun to test ipv6 >>>>>> (luckily supported by my ISP) and ddns. But it feels really hacky. >>>>>> Also deployment is a pain, compared to a traditional webserver. >>>>>> >>>>>> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones >>>>>> a =C3=A9crit : >>>>>> >>>>>>> doesn't work very well on windows uwp. works fine on smartphones >>>>>>> Be the change you want to see in the world ..tom >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 4, 2021 at 11:18 AM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> OK, thanks =E2=80=94 in that case, there are no changes at all to = GNAP, >>>>>>>> which is already HTTP driven. The harder parts tend to be where yo= u can=E2=80=99t >>>>>>>> (or don=E2=80=99t want to) use something like that. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> On Feb 4, 2021, at 2:16 PM, Tom Jones >>>>>>>> wrote: >>>>>>>> >>>>>>>> yes, loopback >>>>>>>> >>>>>>>> Be the change you want to see in the world ..tom >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Feb 4, 2021 at 11:01 AM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Tom, can you expand on how exactly the back-channel communicatio= n >>>>>>>>> works between on-device components? Do you use HTTP locally? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> =E2=80=94 Justin >>>>>>>>> >>>>>>>>> On Feb 4, 2021, at 1:03 PM, Tom Jones < >>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>> >>>>>>>>> Justin's analysis of use of the front channel is misleading. >>>>>>>>> It could equally be argued that what i have done is installed an >>>>>>>>> AS on the phone and the communications with it & the PR is back c= hannel. >>>>>>>>> Basically the point is that the old OIDC paradigms are no longer >>>>>>>>> valid. >>>>>>>>> Be the change you want to see in the world ..tom >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Yes, issue (#168) message based interaction / DIDComm is a >>>>>>>>>> tentative alternative mecanism for the interaction part. Not sur= e how that >>>>>>>>>> would work in details though, prototyping will probably help her= e. >>>>>>>>>> Token delivery through continuation seems fine to me. The client >>>>>>>>>> will probably have to wait for the next polling before it receiv= es a token >>>>>>>>>> issued as the result of an asynchronous interaction, but that's = not a big >>>>>>>>>> issue. >>>>>>>>>> >>>>>>>>>> But the AS on the phone seems like a harder nut to crack, at >>>>>>>>>> least at first sight. I think that would be awesome, but it give= s me >>>>>>>>>> headaches, so I think I'll work on easier stuff right now ;-) >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> One of the biggest drawbacks of the current app-centric >>>>>>>>>>> approaches in OIDC (self-issued OP, or SIOP) is that they depen= d on using >>>>>>>>>>> the front channel and browser redirects to pass everything, whi= ch is >>>>>>>>>>> something that GNAP is deliberately getting away from by starti= ng in the >>>>>>>>>>> back channel. >>>>>>>>>>> >>>>>>>>>>> That said, once a request is kicked off in GNAP, the interactio= n >>>>>>>>>>> and fulfillment can happen through any number of means. Part of= the work >>>>>>>>>>> that=E2=80=99s being done with the =E2=80=9Cinteraction=E2=80= =9D section is going to help >>>>>>>>>>> facilitate this, and I think that there are some other potentia= l branches >>>>>>>>>>> here. >>>>>>>>>>> >>>>>>>>>>> Token delivery is where things get extra weird though =E2=80=94= we are >>>>>>>>>>> explicitly not delivering tokens in the front channel in the co= re of GNAP, >>>>>>>>>>> we=E2=80=99re using the response from the continuation API. One= idea (that isn=E2=80=99t >>>>>>>>>>> particularly well thought out and hasn=E2=80=99t been implement= ed at all) is to >>>>>>>>>>> have an extension declare an alternative response from the =E2= =80=9Ccontinue=E2=80=9D >>>>>>>>>>> section that=E2=80=99s defined today, which points to the GNPA = continuation API. If >>>>>>>>>>> an extension defines some alternative way to deliver tokens, th= at could >>>>>>>>>>> live alongside a continuation API and the client could indicate= support for >>>>>>>>>>> it in its initial request. >>>>>>>>>>> >>>>>>>>>>> In any event, alternative interaction and delivery methods are >>>>>>>>>>> important, and even if we aren=E2=80=99t going to support every= last one of them >>>>>>>>>>> directly, the protocol design should at least be aware of them. >>>>>>>>>>> >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>> >>>>>>>>>>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Tom, >>>>>>>>>>> >>>>>>>>>>> Sure, any experience on that would be greatly appreciated, we'r= e >>>>>>>>>>> calling for help here (the point being that I suspect what they= 're doing is >>>>>>>>>>> not trivial). >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones < >>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> I've had such an app working for over a year. There are issues >>>>>>>>>>>> which are being addressed by the browser Interaction team of o= idc. >>>>>>>>>>>> >>>>>>>>>>>> thx ..Tom (mobile) >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault < >>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Francis, >>>>>>>>>>>>> >>>>>>>>>>>>> I've tried a few things with regards to using the AS on a >>>>>>>>>>>>> phone, but it's really quite complex. >>>>>>>>>>>>> >>>>>>>>>>>>> Making that run on a phone comes with quite a bit of trouble. >>>>>>>>>>>>> The most difficult part if that we'd need to use a secure ele= ment, but just >>>>>>>>>>>>> installing and hosting a http server securely is not a standa= rd setup at >>>>>>>>>>>>> all. I suggest interested people step in to work on this, as = we already >>>>>>>>>>>>> have a lot of work for the (more usual) server case and alrea= dy handle a >>>>>>>>>>>>> privacy preserving scheme. >>>>>>>>>>>>> >>>>>>>>>>>>> Please let us know what you think. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Fabien >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault < >>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Francis, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've thought a bit more to what you said. I think I'll give >>>>>>>>>>>>>> it a try as a separate experiment (in code, not in theory). = Not that I >>>>>>>>>>>>>> would expect it to be included in GNAP, but I kind of like t= he idea :-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> The direct impact for GNAP would be to think about multiple >>>>>>>>>>>>>> ASs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Will let you know. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha < >>>>>>>>>>>>>> fpo@adorsys.de> a =C3=A9crit : >>>>>>>>>>>>>> >>>>>>>>>>>>>>> It would be nice if the protocol was designed at many layer= s >>>>>>>>>>>>>>> of abstraction. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - The first layer shall design abstract protocol flows, >>>>>>>>>>>>>>> without specification of the mode and mechanism of inter= action. >>>>>>>>>>>>>>> - The second layer can instantiate the first layer for >>>>>>>>>>>>>>> dedicated interaction. Here we can talk http, we can def= ine interactions >>>>>>>>>>>>>>> that presume server based token generation, we can defin= e interaction that >>>>>>>>>>>>>>> run on user device based token generation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is also the fundament of the structure I proposed for >>>>>>>>>>>>>>> the spec ( >>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/3= 0 >>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Francis >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>>> *From:* Fabien Imbault >>>>>>>>>>>>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>>>>>>>>>>>>> *To:* Francis Pouatcha >>>>>>>>>>>>>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>>>>>>>>>>>>> dick.hardt@gmail.com>; Tom Jones < >>>>>>>>>>>>>>> thomasclinganjones@gmail.com>; Denis ; >>>>>>>>>>>>>>> Justin Richer >>>>>>>>>>>>>>> *Subject:* Re: [GNAP] Review of >>>>>>>>>>>>>>> draft-ietf-gnap-core-protocol-00 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Would make sense, but not so easy as we rely heavily on >>>>>>>>>>>>>>> HTTP. Hence the discussion about deep links and so on. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> An alternative might be provided by wasm/wasi (running a >>>>>>>>>>>>>>> local sandbox on your phone, for your own AS), but it's rea= lly early stage. >>>>>>>>>>>>>>> This also poses another question that Denis has put forward= , i.e. how do we >>>>>>>>>>>>>>> handle the multiple AS scenario (likely to occur then). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha < >>>>>>>>>>>>>>> fpo@adorsys.de> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We are drifting away from the original problem space. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - My original mention was about the "POST" request, that >>>>>>>>>>>>>>> subsumes that the "AS" is a "Server". Designing a new pr= otocol, we cannot >>>>>>>>>>>>>>> afford this limitation. >>>>>>>>>>>>>>> - I just mentioned SIOP to show a known and closed >>>>>>>>>>>>>>> example? Let us not focus on the device local discovery = scheme (like >>>>>>>>>>>>>>> openid:) for now. >>>>>>>>>>>>>>> - As capability of holding private keys on user device >>>>>>>>>>>>>>> evolves, server-based issuing of token will be fading ou= t giving way to >>>>>>>>>>>>>>> device local generation of token. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> While designing GNAP, let us assume the AS-Role can be >>>>>>>>>>>>>>> exercised on a user device and design the protocol to honor= that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> /Francis >>>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>>> *From:* TXAuth on behalf of Dick >>>>>>>>>>>>>>> Hardt >>>>>>>>>>>>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>>>>>>>>>>>>> *To:* Tom Jones >>>>>>>>>>>>>>> *Cc:* Fabien Imbault ; Denis < >>>>>>>>>>>>>>> denis.ietf@free.fr>; GNAP Mailing List ; >>>>>>>>>>>>>>> Justin Richer >>>>>>>>>>>>>>> *Subject:* Re: [GNAP] Review of >>>>>>>>>>>>>>> draft-ietf-gnap-core-protocol-00 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Got it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So web apps invoke a openid: deep link and hope there is an >>>>>>>>>>>>>>> app to handle the openid: scheme? ... and that it is the us= er's wallet >>>>>>>>>>>>>>> rather than some malware that has registered openid: on the= mobile device? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A native app can attempt to open a deep link associated wit= h >>>>>>>>>>>>>>> an app, and will fail if the app is not there. If the app i= s there, it will >>>>>>>>>>>>>>> be opened, so this can't be used to silently test if an app= is present, but >>>>>>>>>>>>>>> it does allow a native app to provide an alternative experi= ence if an app >>>>>>>>>>>>>>> is not present. I don't think this works with custom scheme= s ... and I >>>>>>>>>>>>>>> don't know how it could work from a web app on the phone wi= th the current >>>>>>>>>>>>>>> Safari APIs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Apple warns against using custom schemes [1] ... but perhap= s >>>>>>>>>>>>>>> they can be convinced to make openid: a managed scheme simi= lar to mailto:, >>>>>>>>>>>>>>> tel:, sms:, facetime: ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>> https://developer.apple.com/documentation/xcode/allowing_ap= ps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_yo= ur_app >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>>>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You are - that is not standard which is opeind:// >>>>>>>>>>>>>>> This is the one step that still needs to be optimized for >>>>>>>>>>>>>>> SIOP to have good UX. >>>>>>>>>>>>>>> Peace ..tom >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt < >>>>>>>>>>>>>>> dick.hardt@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Tom >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I watched your video (I watched at 2X speed) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Looks like the employment website app that is using >>>>>>>>>>>>>>> localhost:8765 to communicate with the wallet. Am I correct= ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Dick >>>>>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones < >>>>>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Well, here's a demo. Note that in this case the AS is not >>>>>>>>>>>>>>> online all of the time, so it is really implicit flow and t= he OIDC id-token >>>>>>>>>>>>>>> comes from the siop device directly. >>>>>>>>>>>>>>> (whether this is front-channel or back channel is no longer >>>>>>>>>>>>>>> an interesting question.) >>>>>>>>>>>>>>> Now if an always-on AS is required, that is possible, but >>>>>>>>>>>>>>> probably beyond the scope of this effort and would require = something like >>>>>>>>>>>>>>> an agent-in-the-sky (with diamonds). >>>>>>>>>>>>>>> here is the link to the 9 min video https://youtu.be >>>>>>>>>>>>>>> /Tq4hw7X5SW0 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Peace ..tom >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer < >>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ultimately, in most situations like these in the real world= , >>>>>>>>>>>>>>> the hurdle isn=E2=80=99t technical compatibility so much as= it is trust >>>>>>>>>>>>>>> compatibility. The RP (client) needs to have some incentive= to trust the >>>>>>>>>>>>>>> assertions and identity information that=E2=80=99s coming f= rom the AS. The same is >>>>>>>>>>>>>>> true for an RS trusting tokens from the AS. The hard questi= on is less =E2=80=9Chow=E2=80=9D >>>>>>>>>>>>>>> to do that (which SSI answers), but more =E2=80=9Cwhy=E2=80= =9D to do that (which SSI >>>>>>>>>>>>>>> doesn=E2=80=99t answer very well, because it=E2=80=99s a ha= rd question). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Still: it=E2=80=99s definitely a question about how to supp= ort this >>>>>>>>>>>>>>> =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got t= he start of it more than OAuth2/OIDC >>>>>>>>>>>>>>> have by allowing the bootstrap of the process from a starti= ng call: the >>>>>>>>>>>>>>> interaction and continuation URIs handed back by the AS don= =E2=80=99t need to be >>>>>>>>>>>>>>> the same URIs that the client starts with, so just like SIO= P the process >>>>>>>>>>>>>>> can start in HTTP and potentially move to other communicati= on channels. A >>>>>>>>>>>>>>> major difference is that we aren=E2=80=99t dependent on the= assumption that the >>>>>>>>>>>>>>> user will always be in a browser at some stage, and so the = whole raft of >>>>>>>>>>>>>>> front-channel messages that SIOP relies on doesn=E2=80=99t = fly. That said, we=E2=80=99ve >>>>>>>>>>>>>>> got an opportunity to more explicitly open up alternative c= ommunication >>>>>>>>>>>>>>> channels here, and that=E2=80=99s something I=E2=80=99d lik= e to see engineered, even if >>>>>>>>>>>>>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concre= te proposal as to how that would >>>>>>>>>>>>>>> work over specific protocols, starting with what we=E2=80= =99ve got today. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault < >>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Denis, hi Francis, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> At some point integration with SSI (on the authentication >>>>>>>>>>>>>>> side) will probably occur, including amongst other possibil= ities SIOP >>>>>>>>>>>>>>> (since they work with OpenID a part of the work will probab= ly be made >>>>>>>>>>>>>>> easier). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That being said, Denis is right. It's not an AS. Technicall= y >>>>>>>>>>>>>>> it's entirely possible to rely on a decentralized wallet (f= or instance on >>>>>>>>>>>>>>> your phone) and a centralized AS. I know of a few studies o= n how to >>>>>>>>>>>>>>> decentralize the AS itself (for instance >>>>>>>>>>>>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentrali= zed-02 >>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>> Maybe it exists, but I'm still looking for real scenarios >>>>>>>>>>>>>>> (or even architectures) where an AS is deployed directly on= a phone, and >>>>>>>>>>>>>>> under the sole authority of the RO, while being compatible = with the rest of >>>>>>>>>>>>>>> the world. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello Francis, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> See two comments in line. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> B) Current Document >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Roles description shall not hold any assumption on the >>>>>>>>>>>>>>> physical structure of the party fulfilling the roles. >>>>>>>>>>>>>>> [FI] not sure what you mean >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [FP] for example, we assume the AS is a server! In most SS= I >>>>>>>>>>>>>>> based use cases, the AS will be running on the user device.= See SIOP ( >>>>>>>>>>>>>>> https://identity.foundation/did-siop/). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I browsed through the two drafts, i.e. : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Decentralized Identifiers (DIDs) v1.0 Core >>>>>>>>>>>>>>> architecture, data model, and representations W3C Workin= g Draft 08 November >>>>>>>>>>>>>>> 2020 >>>>>>>>>>>>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. >>>>>>>>>>>>>>> DIF Working Group Draft >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> At no place within these two documents, it is possible to >>>>>>>>>>>>>>> imagine that "the AS will be running on the user device". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From section 3 of the DIF Working Group Draft: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "Unlike the OIDC Authorization Code Flow as per >>>>>>>>>>>>>>> [OIDC.Core], the SIOP will not return an access token to th= e RP". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> An Identity Wallet is not an AS. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Roles: >>>>>>>>>>>>>>> -> grant endpoint of the AS: Why is this a post request? >>>>>>>>>>>>>>> This eliminates the chance of having user device hosted AS = (no server). >>>>>>>>>>>>>>> [FI] what would you propose instead? >>>>>>>>>>>>>>> Would also be interested to understand better the deploymen= t >>>>>>>>>>>>>>> model when there is no server. That's something that was di= scussed several >>>>>>>>>>>>>>> times but I'm still missing the underlying architecture and= use case. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [FP] See above (SIOP). There will be a lot of identity >>>>>>>>>>>>>>> wallets operated on end user device. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> See the above comment. Please, do not confuse an Identity >>>>>>>>>>>>>>> Wallet with an Authentication Server (AS). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Denis >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it >>>>>>>>>>>>>>> authorize the request or the access to a resource? >>>>>>>>>>>>>>> [FI] yes, we should make the wording clearer >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Missing Section Interactions: >>>>>>>>>>>>>>> --> This section shall introduce the notion of interaction >>>>>>>>>>>>>>> before we start listing interaction types. >>>>>>>>>>>>>>> [FI] yes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Interaction Types: >>>>>>>>>>>>>>> --> I prefer a classification with Redirect, Decoupled and >>>>>>>>>>>>>>> Embedded is. In the draft, we have one redirect and 2 decou= ple interactions >>>>>>>>>>>>>>> and nothing else. >>>>>>>>>>>>>>> [FI] this should be handled as a specific discussion item. >>>>>>>>>>>>>>> As a reminder, how would you define embedded? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In practice there's at least these modes: >>>>>>>>>>>>>>> - redirect and redirect back >>>>>>>>>>>>>>> - redirect to different browser or device >>>>>>>>>>>>>>> - user code >>>>>>>>>>>>>>> - CIBA >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [FP] This classification is limited. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Redirect: same device, same or different user agents >>>>>>>>>>>>>>> (browser, mobile app, desktop app, ...) >>>>>>>>>>>>>>> - Decoupled: different devices >>>>>>>>>>>>>>> - Embedded : RC carries RO authorization to AS >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Resource Access Request vs. Resource Request >>>>>>>>>>>>>>> --> Both are mixed up. No clarification of the context of >>>>>>>>>>>>>>> each section. >>>>>>>>>>>>>>> [FI] could you clarify what you'd expect. Btw on this >>>>>>>>>>>>>>> topic, there's a more general discussion on whether we shou= ld make a >>>>>>>>>>>>>>> distinction or not. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [FP]: Here: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Resource Access Request: Requesting Access to a >>>>>>>>>>>>>>> resource. Response is an access token (or any type of gr= ant) >>>>>>>>>>>>>>> - Resource Request: Request the resource. Response is >>>>>>>>>>>>>>> the resource (or a corresponding execution) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Token Content Negotiation >>>>>>>>>>>>>>> --> Not expressed as such. This is central to GNAP and not >>>>>>>>>>>>>>> represented enough in the document. >>>>>>>>>>>>>>> [FI] right. This should be a specific discussion item. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Requesting "User" Information >>>>>>>>>>>>>>> we identify two types of users: RQ and RO. It will be bette= r >>>>>>>>>>>>>>> not to refer to a user in this draft, but either to a RQ or= an RO. >>>>>>>>>>>>>>> [FI] yes that would avoid potential misunderstandings. >>>>>>>>>>>>>>> Although in the end, people will translate RQ into user or = end-user most of >>>>>>>>>>>>>>> the time. Cf in definition, currently we have Requesting >>>>>>>>>>>>>>> Party (RQ, aka "user") >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Interaction Again >>>>>>>>>>>>>>> -> For each interaction type, we will have to describe the >>>>>>>>>>>>>>> protocol flow and the nature and behavior of involved Roles= (Parties), >>>>>>>>>>>>>>> Elements, Requests. >>>>>>>>>>>>>>> [FI] yes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [FP] Will these and into tickets? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards. >>>>>>>>>>>>>>> /Francis >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>> TXAuth mailing list >>>>>>>>> TXAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>> >>>>> --000000000000125ef505ba9a8782 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No, you didn't misunderstand me. It's just that t= he ux for that is not acceptable to retail users. As long as gnap sticks to= industrial users you should do fine.

thx ..Tom (mobile)

On Fri, Feb 5, 2021, 7:56 AM Fabien Imbau= lt <fabien.imbault@gmail.com= > wrote:
Targeting existing browsers and types of applications = (web, pwa, mobile, etc.) seems like a reasonable option for an industrial s= tandard. Improving security, privacy, ease of use and interoperability (inc= luding decentralized identity as well) should be good enough objectives.=C2= =A0
Plus from our previous discussions, I was under the impressio= n you were fine with the approach of deploying the AS on the phone as a loo= pback, for mobile apps. Did I miss something?

Cheers,
Fabien

Le ven. 5 f=C3=A9v= r. 2021 =C3=A0 16:33, Tom Jones <thomasclinganjones@gmail.com<= /a>> a =C3=A9crit=C2=A0:



On = Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault <fabien.imba= ult@gmail.com> wrote:
Hi Tom,= =C2=A0

Thanks, your resp= onses made it clearer for me what you expect from an AS deployed on a mobil= e.=C2=A0

I think we'= re on the right path to meet the rest of your concerns. There are already a= few items on these:
- privacy preserving techniques= have been discussed and are likely to be included (I think). It's been= recognized as a core concern=C2=A0
- not exactly su= re the meaning you give to discovery here (it's already been used in th= e WG but with a different meaning I believe). The request or the continuati= on api provide entry points to pay attention to.=C2=A0

Is that enough for your use case ? Do you need something = else ? (like SSE?)

Cheer= s
Fabien=C2=A0

Le jeu. 4 f=C3=A9vr. 2021= =C3=A0 22:10, Tom Jones <thomasclinganjones@gmail.com&g= t; a =C3=A9crit=C2=A0:
discovery is the prime problem.=C2=A0 What causes t= he wallet/AS to wake up and pay attention. How does the RP know what to ask= for without violating user privacy rights?

CHAPI would = be ok i guess, but that requires cred man to be fixed. Not sure if it fixes= discovery or privacy even then.

Be the change you want to see in the world ..tom


=
On Thu, Feb 4, 2021 at 12:45 PM Justi= n Richer <jricher@mit.edu> wrote:
Tom, what additional functionali= ty do you see that a browser would need to support in order for GNAP to be = adopted? For the elements of the core protocol today, nothing is needed to = change within the browsers =E2=80=94 everything is built on existing functi= ons. GNAP uses browsers as a tool, and I would argue depends on them even l= ess so than OAuth 2 does. Extensions could use browser functionality, like = using CHAPI to pass interaction elements, but the core protocol functions o= n vanilla browsers today.

=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 3:20 PM, Tom Jones &= lt;thomasclinganjones@gmail.com> wrote:
=
i assumed that the wallet (aka AS) needed to be a= native app, not a PWA (which can come from a traditional web server).
= There are folks, lke Kim C, who are working on a PWA, but i agree the block= s there seem to be large.
THe blocks on a native app are simple, = easy to describe, and easy to ask the browser guys to fix. Not sure if they= care tho.
I have trouble seeing a path to GNAP adoption for reta= il customers w/o some browser support.
That's why i am mostly= =C2=A0silent here.

Be the change yo= u want to see in the world ..tom


On= Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault <fabien.= imbault@gmail.com> wrote:
Fair enough. But loopback limits a lot w= hat you can do... Just for debug it's a pain.=C2=A0
Bu= t as soon as you try more, it's a bit crazy. Fun to test ipv6 (luckily = supported by my ISP) and ddns. But it feels really hacky.=C2=A0
Also deployment is a pain, compared to a traditional webserver.= =C2=A0

Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones <thomasclinganjo= nes@gmail.com> a =C3=A9crit=C2=A0:
doesn't work very well on wi= ndows uwp. works fine on smartphones
Be t= he change you want to see in the world ..tom
=

On Thu, Feb 4, 2021 at 11:18 AM Justin Richer <jricher@mit.edu> w= rote:
OK, t= hanks =E2=80=94 in that case, there are no changes at all to GNAP, which is= already HTTP driven. The harder parts tend to be where you can=E2=80=99t (= or don=E2=80=99t want to) use something like that.

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

On Feb 4, 20= 21, at 2:16 PM, Tom Jones <thomasclinganjones@gmail.com> wrote= :

yes, loopback

Be the change you want to see in the world ..tom
=


On Thu, Feb 4, 2021 at 11:01 AM Justin Richer= <jrich= er@mit.edu> wrote:
Tom, can you expand on how exactly the back-channel =C2=A0c= ommunication works between on-device components? Do you use HTTP locally?
Thanks,
=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 1:03 PM, Tom Jones <tho= masclinganjones@gmail.com> wrote:

Jus= tin's analysis of use of the front channel is misleading.
It could = equally be argued that what i have done is installed an AS on the phone and= the communications with it & the PR is back channel.
Basical= ly the point is that the old OIDC paradigms are no longer valid.
Be the change you want to see in the world ..to= m


On Thu, Feb 4, 2021 at 7:47 AM Fabien Im= bault <fabien.imbault@gmail.com> wrote:
Yes, issue (#168)=C2=A0me= ssage based interaction / DIDComm is a tentative alternative mecanism for t= he interaction part. Not sure how that would work in details=C2=A0though, p= rototyping will probably help here.
Token delivery=C2=A0through continu= ation seems fine to me. The client will probably have to wait for the next = polling before it receives a token issued as the result of an asynchronous = interaction, but that's not a big issue.

But t= he AS on the phone seems like a harder nut to crack, at least at first sigh= t. I think that would be awesome, but it gives me headaches, so I think I&#= 39;ll work on easier stuff right now ;-)

Fabien=C2= =A0=C2=A0

On Thu, Feb 4, 2021 at 4:30 PM Justin Richer <jricher@mit.edu> wrote:
One of the biggest drawbacks of the current app-centric approaches in OI= DC (self-issued OP, or SIOP) is that they depend on using the front channel= and browser redirects to pass everything, which is something that GNAP is = deliberately getting away from by starting in the back channel.

That said, once a request is kicked off in GNAP, the interaction an= d fulfillment can happen through any number of means. Part of the work that= =E2=80=99s being done with the =E2=80=9Cinteraction=E2=80=9D section is goi= ng to help facilitate this, and I think that there are some other potential= branches here.

Token delivery is where things get= extra weird though =E2=80=94 we are explicitly not delivering tokens in th= e front channel in the core of GNAP, we=E2=80=99re using the response from = the continuation API. One idea (that isn=E2=80=99t particularly well though= t out and hasn=E2=80=99t been implemented at all) is to have an extension d= eclare an alternative response from the =E2=80=9Ccontinue=E2=80=9D section = that=E2=80=99s defined today, which points to the GNPA continuation API. If= an extension defines some alternative way to deliver tokens, that could li= ve alongside a continuation API and the client could indicate support for i= t in its initial request.

In any event, alternativ= e interaction and delivery methods are important, and even if we aren=E2=80= =99t going to support every last one of them directly, the protocol design = should at least be aware of them.

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


=
Hi Tom,=C2=A0

Sure, any experience on t= hat would be greatly appreciated, we're calling for help here (the poin= t being that I suspect what they're doing is not trivial).
Fabien

On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <th= omasclinganjones@gmail.com> wrote:
I've had such an app workin= g for over a year. There are issues which are being addressed by the browse= r Interaction team of oidc.

thx ..Tom (mobile)

<= div class=3D"gmail_quote">
On Thu, Feb= 4, 2021, 3:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:=
Hi Francis,=C2=A0

I've tried a few things with reg= ards to using the AS on a phone, but it's really quite=C2=A0complex.=C2= =A0

Making that run on a phone comes with quite a = bit of trouble. The most difficult part if that we'd need to use a secu= re element, but just installing and hosting a http server securely is not a= standard setup at all. I suggest interested people step in to work on this= , as we already have a lot of work for the (more usual) server case and alr= eady handle a privacy preserving scheme.=C2=A0

Ple= ase let us know what you think.

Cheers,
= Fabien=C2=A0

On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,

I've thought a bit more to what you sa= id. I think I'll give it a try as a separate experiment (in code, not i= n theory). Not that I would expect it to be included in GNAP, but I kind of= like the idea :-)

The d= irect impact for GNAP would be to think about multiple ASs.=C2=A0

Will let you know.=C2=A0

Fabien=C2=A0


Le mer. 18 nov. = 2020 =C3=A0 13:06, Francis Pouatcha <fpo@adorsys.de> a =C3=A9crit= =C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"m_4588137701409402545m_3740723253088693496m_-99671316316621892gmail-m_4= 891442230495737020m_-8218552788289986907m_-8518815978092546954m_35504198008= 36567560m_-8251187544229342067m_6649396458130137896m_3308803089207789488m_-= 435436554859614529m_2888166142485750597gmail-m_7901394266816005280gmail-m_-= 6718184999452512077m_-3004232231493229381m_-8862550958674531306m_4552653984= 562635461m_387929924441527190m_6662104191003806385gmail-m_-5428390703410233= 88gmail-m_-6176056956474019294gmail-m_-3037161202240578685gmail-m_-75203894= 57378808664gmail-m_-3342024782330569254m_8014700032835912204gmail-m_1426518= 73244800559m_8348797445460806175LPlnk338391" rel=3D"noreferrer noreferrer n= oreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer= noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferr= er" target=3D"_blank">https://github.com/ietf-wg-gnap/gnap-core-protocol/is= sues/30).

/Francis

From: Fabien Imba= ult <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org<= /a>>; Dick Hardt <dick.hardt@gmail.com>; Tom = Jones <thomasclinganjones@gmail.com>; De= nis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@adorsys.de> wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.= com>
Cc: Fabien Imbault <fabien.imbault@gmail.com= >; Denis <denis.ietf@free.fr>; GNAP Mailing= List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <= fabien.imbault@gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentral= ized-02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <d= enis.ietf@free.fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foun= dation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= [FP]: Her= e:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txa= uth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org= /mailman/listinfo/txauth


--
TXAuth mailing list
TXAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/txauth

--000000000000125ef505ba9a8782-- From nobody Fri Feb 5 10:07:52 2021 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 6B7C33A0A3E for ; Fri, 5 Feb 2021 10:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 ipwV_gkK63yk for ; Fri, 5 Feb 2021 10:07:45 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 9CA793A0A1D for ; Fri, 5 Feb 2021 10:07:45 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id n14so8086019iog.3 for ; Fri, 05 Feb 2021 10:07:45 -0800 (PST) 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=Y4nHNsKnIwVnKjhI4S/EiBPirZ2Tx363Vbga/92s7KI=; b=bf1yK6PGUz0DJGC+H3bXAZTShBtxzhqQJnweuSg4Pxp+Nn4VMWbPDC16wGdr3Q6/l3 0LdNO06xyuc1gGOVBqUyDDEDj/T5fU/nmg+AT7v2z/m7U3TyLMyfSloA6ynKxeHz45ou 2eB0UWnEYeAGI71JbCWt8giFRbLeaV4wiam5tgddivQWVLFXZ2dga/Ree0UpUtt6ndBN +vUDgT/QFIiKDG9rOF9XPZZAe6iyIc12ne2WmWFZfPHnqATpb18aSSKAZqbrzA9BXLOK 6+BpfaDqzMFWK/2UoURj/Ck9c5lFnbsz+v+zKWLRfL4QajXQc1jOOk1mXm2IsXQoT/AA x2ow== 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=Y4nHNsKnIwVnKjhI4S/EiBPirZ2Tx363Vbga/92s7KI=; b=XS7c+PIrZ6eWLiLTKQyAkJdjQSjX91ECQkft6wlpbwPlnFTwHb3Yu3fvKhyhesJnRP wUyseq7Iyl5zrL3yV88AZE8oX4Go7/WtVg/fazSMAu7Q3iWZlzS41Z03mR3bXrD2kKtp 074/D3Do0TBMuJL90HEIkUAptvikqiqeTbZTKGTlFLICCozyDd0ucbVFF6SMqAbMX8X3 87OXIOfQJu+9StAMM6nW17sHNK95vNDBVKl2SrJFenUz9Joe3a5YyzvdyMO9dvB0S7hu c1zTEQo2dN2cfpoMpXrbFK2n+IQi9Vb1bFsFLsSiPrW4D7RRVFEjXGKSSo4Ze4/Pzyvd HF/g== X-Gm-Message-State: AOAM533c3OJakL5ITjOvYGpum8HO4+9+heHRifZUIdHRTUIl6EVkQZtY vUrK2wT71tphRoT9bWurG2zTLI+T3dw+uRZaNw4= X-Google-Smtp-Source: ABdhPJyDbNk4aLL8YtA6kavnrKBzCflcv3TJa43bl6y6YeAREvMhINsvcVMWtYL+ZkFwDpw7cRNk5KIpF00rhzfjTRg= X-Received: by 2002:a6b:c8d0:: with SMTP id y199mr5124373iof.162.1612548464633; Fri, 05 Feb 2021 10:07:44 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> <77D1AE7B-076F-4095-8FAA-7C35D74614BD@mit.edu> In-Reply-To: From: Fabien Imbault Date: Fri, 5 Feb 2021 19:07:29 +0100 Message-ID: To: Tom Jones Cc: Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="0000000000006aee8a05ba9ab2c9" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 18:07:51 -0000 --0000000000006aee8a05ba9ab2c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Probably (and to be honest even for industrial users I find it complex), but alternatives are not ready for prime time either. Maybe some day DIDComm could be useful as a basic block, what we suggest is to first use that as a potential interaction (and there's already a lot of questions that arise just from that). Fabien On Fri, Feb 5, 2021 at 6:55 PM Tom Jones wrote: > No, you didn't misunderstand me. It's just that the ux for that is not > acceptable to retail users. As long as gnap sticks to industrial users yo= u > should do fine. > > thx ..Tom (mobile) > > On Fri, Feb 5, 2021, 7:56 AM Fabien Imbault > wrote: > >> Targeting existing browsers and types of applications (web, pwa, mobile, >> etc.) seems like a reasonable option for an industrial standard. Improvi= ng >> security, privacy, ease of use and interoperability (including >> decentralized identity as well) should be good enough objectives. >> Plus from our previous discussions, I was under the impression you were >> fine with the approach of deploying the AS on the phone as a loopback, f= or >> mobile apps. Did I miss something? >> >> Cheers, >> Fabien >> >> Le ven. 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones a >> =C3=A9crit : >> >>> If you mean can GNAP work on old fashioned apps running with existing >>> browsers and existing identity providers, then yes, i guess you are ok. >>> >>> If you want to work on apps where the user is in control of authn and >>> authz, then no, GNAP cannot work. It is not alone in that OIDC wont wor= k >>> there either. >>> >>> Be the change you want to see in the world ..tom >>> >>> >>> On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault >>> wrote: >>> >>>> Hi Tom, >>>> >>>> Thanks, your responses made it clearer for me what you expect from an >>>> AS deployed on a mobile. >>>> >>>> I think we're on the right path to meet the rest of your concerns. >>>> There are already a few items on these: >>>> - privacy preserving techniques have been discussed and are likely to >>>> be included (I think). It's been recognized as a core concern >>>> - not exactly sure the meaning you give to discovery here (it's alread= y >>>> been used in the WG but with a different meaning I believe). The reque= st or >>>> the continuation api provide entry points to pay attention to. >>>> >>>> Is that enough for your use case ? Do you need something else ? (like >>>> SSE?) >>>> >>>> Cheers >>>> Fabien >>>> >>>> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom Jones >>>> a =C3=A9crit : >>>> >>>>> discovery is the prime problem. What causes the wallet/AS to wake up >>>>> and pay attention. How does the RP know what to ask for without viola= ting >>>>> user privacy rights? >>>>> >>>>> CHAPI would be ok i guess, but that requires cred man to be fixed. No= t >>>>> sure if it fixes discovery or privacy even then. >>>>> >>>>> Be the change you want to see in the world ..tom >>>>> >>>>> >>>>> On Thu, Feb 4, 2021 at 12:45 PM Justin Richer wrote= : >>>>> >>>>>> Tom, what additional functionality do you see that a browser would >>>>>> need to support in order for GNAP to be adopted? For the elements of= the >>>>>> core protocol today, nothing is needed to change within the browsers= =E2=80=94 >>>>>> everything is built on existing functions. GNAP uses browsers as a t= ool, >>>>>> and I would argue depends on them even less so than OAuth 2 does. >>>>>> Extensions could use browser functionality, like using CHAPI to pass >>>>>> interaction elements, but the core protocol functions on vanilla bro= wsers >>>>>> today. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Feb 4, 2021, at 3:20 PM, Tom Jones >>>>>> wrote: >>>>>> >>>>>> i assumed that the wallet (aka AS) needed to be a native app, not a >>>>>> PWA (which can come from a traditional web server). >>>>>> There are folks, lke Kim C, who are working on a PWA, but i agree th= e >>>>>> blocks there seem to be large. >>>>>> THe blocks on a native app are simple, easy to describe, and easy to >>>>>> ask the browser guys to fix. Not sure if they care tho. >>>>>> I have trouble seeing a path to GNAP adoption for retail customers >>>>>> w/o some browser support. >>>>>> That's why i am mostly silent here. >>>>>> >>>>>> Be the change you want to see in the world ..tom >>>>>> >>>>>> >>>>>> On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Fair enough. But loopback limits a lot what you can do... Just for >>>>>>> debug it's a pain. >>>>>>> But as soon as you try more, it's a bit crazy. Fun to test ipv6 >>>>>>> (luckily supported by my ISP) and ddns. But it feels really hacky. >>>>>>> Also deployment is a pain, compared to a traditional webserver. >>>>>>> >>>>>>> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones < >>>>>>> thomasclinganjones@gmail.com> a =C3=A9crit : >>>>>>> >>>>>>>> doesn't work very well on windows uwp. works fine on smartphones >>>>>>>> Be the change you want to see in the world ..tom >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Feb 4, 2021 at 11:18 AM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> OK, thanks =E2=80=94 in that case, there are no changes at all to= GNAP, >>>>>>>>> which is already HTTP driven. The harder parts tend to be where y= ou can=E2=80=99t >>>>>>>>> (or don=E2=80=99t want to) use something like that. >>>>>>>>> >>>>>>>>> =E2=80=94 Justin >>>>>>>>> >>>>>>>>> On Feb 4, 2021, at 2:16 PM, Tom Jones < >>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>> >>>>>>>>> yes, loopback >>>>>>>>> >>>>>>>>> Be the change you want to see in the world ..tom >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Feb 4, 2021 at 11:01 AM Justin Richer >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Tom, can you expand on how exactly the back-channel >>>>>>>>>> communication works between on-device components? Do you use HT= TP locally? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>> >>>>>>>>>> On Feb 4, 2021, at 1:03 PM, Tom Jones < >>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> Justin's analysis of use of the front channel is misleading. >>>>>>>>>> It could equally be argued that what i have done is installed an >>>>>>>>>> AS on the phone and the communications with it & the PR is back = channel. >>>>>>>>>> Basically the point is that the old OIDC paradigms are no longer >>>>>>>>>> valid. >>>>>>>>>> Be the change you want to see in the world ..tom >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Yes, issue (#168) message based interaction / DIDComm is a >>>>>>>>>>> tentative alternative mecanism for the interaction part. Not su= re how that >>>>>>>>>>> would work in details though, prototyping will probably help he= re. >>>>>>>>>>> Token delivery through continuation seems fine to me. The clien= t >>>>>>>>>>> will probably have to wait for the next polling before it recei= ves a token >>>>>>>>>>> issued as the result of an asynchronous interaction, but that's= not a big >>>>>>>>>>> issue. >>>>>>>>>>> >>>>>>>>>>> But the AS on the phone seems like a harder nut to crack, at >>>>>>>>>>> least at first sight. I think that would be awesome, but it giv= es me >>>>>>>>>>> headaches, so I think I'll work on easier stuff right now ;-) >>>>>>>>>>> >>>>>>>>>>> Fabien >>>>>>>>>>> >>>>>>>>>>> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> One of the biggest drawbacks of the current app-centric >>>>>>>>>>>> approaches in OIDC (self-issued OP, or SIOP) is that they depe= nd on using >>>>>>>>>>>> the front channel and browser redirects to pass everything, wh= ich is >>>>>>>>>>>> something that GNAP is deliberately getting away from by start= ing in the >>>>>>>>>>>> back channel. >>>>>>>>>>>> >>>>>>>>>>>> That said, once a request is kicked off in GNAP, the >>>>>>>>>>>> interaction and fulfillment can happen through any number of m= eans. Part of >>>>>>>>>>>> the work that=E2=80=99s being done with the =E2=80=9Cinteracti= on=E2=80=9D section is going to help >>>>>>>>>>>> facilitate this, and I think that there are some other potenti= al branches >>>>>>>>>>>> here. >>>>>>>>>>>> >>>>>>>>>>>> Token delivery is where things get extra weird though =E2=80= =94 we are >>>>>>>>>>>> explicitly not delivering tokens in the front channel in the c= ore of GNAP, >>>>>>>>>>>> we=E2=80=99re using the response from the continuation API. On= e idea (that isn=E2=80=99t >>>>>>>>>>>> particularly well thought out and hasn=E2=80=99t been implemen= ted at all) is to >>>>>>>>>>>> have an extension declare an alternative response from the =E2= =80=9Ccontinue=E2=80=9D >>>>>>>>>>>> section that=E2=80=99s defined today, which points to the GNPA= continuation API. If >>>>>>>>>>>> an extension defines some alternative way to deliver tokens, t= hat could >>>>>>>>>>>> live alongside a continuation API and the client could indicat= e support for >>>>>>>>>>>> it in its initial request. >>>>>>>>>>>> >>>>>>>>>>>> In any event, alternative interaction and delivery methods are >>>>>>>>>>>> important, and even if we aren=E2=80=99t going to support ever= y last one of them >>>>>>>>>>>> directly, the protocol design should at least be aware of them= . >>>>>>>>>>>> >>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>> >>>>>>>>>>>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault < >>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Tom, >>>>>>>>>>>> >>>>>>>>>>>> Sure, any experience on that would be greatly appreciated, >>>>>>>>>>>> we're calling for help here (the point being that I suspect wh= at they're >>>>>>>>>>>> doing is not trivial). >>>>>>>>>>>> >>>>>>>>>>>> Fabien >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones < >>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I've had such an app working for over a year. There are issue= s >>>>>>>>>>>>> which are being addressed by the browser Interaction team of = oidc. >>>>>>>>>>>>> >>>>>>>>>>>>> thx ..Tom (mobile) >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault < >>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Francis, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've tried a few things with regards to using the AS on a >>>>>>>>>>>>>> phone, but it's really quite complex. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Making that run on a phone comes with quite a bit of trouble= . >>>>>>>>>>>>>> The most difficult part if that we'd need to use a secure el= ement, but just >>>>>>>>>>>>>> installing and hosting a http server securely is not a stand= ard setup at >>>>>>>>>>>>>> all. I suggest interested people step in to work on this, as= we already >>>>>>>>>>>>>> have a lot of work for the (more usual) server case and alre= ady handle a >>>>>>>>>>>>>> privacy preserving scheme. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please let us know what you think. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault < >>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Francis, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've thought a bit more to what you said. I think I'll give >>>>>>>>>>>>>>> it a try as a separate experiment (in code, not in theory).= Not that I >>>>>>>>>>>>>>> would expect it to be included in GNAP, but I kind of like = the idea :-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The direct impact for GNAP would be to think about multiple >>>>>>>>>>>>>>> ASs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Will let you know. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha < >>>>>>>>>>>>>>> fpo@adorsys.de> a =C3=A9crit : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It would be nice if the protocol was designed at many >>>>>>>>>>>>>>>> layers of abstraction. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - The first layer shall design abstract protocol flows, >>>>>>>>>>>>>>>> without specification of the mode and mechanism of inte= raction. >>>>>>>>>>>>>>>> - The second layer can instantiate the first layer for >>>>>>>>>>>>>>>> dedicated interaction. Here we can talk http, we can de= fine interactions >>>>>>>>>>>>>>>> that presume server based token generation, we can defi= ne interaction that >>>>>>>>>>>>>>>> run on user device based token generation. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is also the fundament of the structure I proposed for >>>>>>>>>>>>>>>> the spec ( >>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/= 30 >>>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Francis >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>>>> *From:* Fabien Imbault >>>>>>>>>>>>>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>>>>>>>>>>>>>> *To:* Francis Pouatcha >>>>>>>>>>>>>>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>>>>>>>>>>>>>> dick.hardt@gmail.com>; Tom Jones < >>>>>>>>>>>>>>>> thomasclinganjones@gmail.com>; Denis ; >>>>>>>>>>>>>>>> Justin Richer >>>>>>>>>>>>>>>> *Subject:* Re: [GNAP] Review of >>>>>>>>>>>>>>>> draft-ietf-gnap-core-protocol-00 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Would make sense, but not so easy as we rely heavily on >>>>>>>>>>>>>>>> HTTP. Hence the discussion about deep links and so on. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> An alternative might be provided by wasm/wasi (running a >>>>>>>>>>>>>>>> local sandbox on your phone, for your own AS), but it's re= ally early stage. >>>>>>>>>>>>>>>> This also poses another question that Denis has put forwar= d, i.e. how do we >>>>>>>>>>>>>>>> handle the multiple AS scenario (likely to occur then). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha < >>>>>>>>>>>>>>>> fpo@adorsys.de> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We are drifting away from the original problem space. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - My original mention was about the "POST" request, >>>>>>>>>>>>>>>> that subsumes that the "AS" is a "Server". Designing a = new protocol, we >>>>>>>>>>>>>>>> cannot afford this limitation. >>>>>>>>>>>>>>>> - I just mentioned SIOP to show a known and closed >>>>>>>>>>>>>>>> example? Let us not focus on the device local discovery= scheme (like >>>>>>>>>>>>>>>> openid:) for now. >>>>>>>>>>>>>>>> - As capability of holding private keys on user device >>>>>>>>>>>>>>>> evolves, server-based issuing of token will be fading o= ut giving way to >>>>>>>>>>>>>>>> device local generation of token. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> While designing GNAP, let us assume the AS-Role can be >>>>>>>>>>>>>>>> exercised on a user device and design the protocol to hono= r that. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> /Francis >>>>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>>>> *From:* TXAuth on behalf of Dick >>>>>>>>>>>>>>>> Hardt >>>>>>>>>>>>>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>>>>>>>>>>>>>> *To:* Tom Jones >>>>>>>>>>>>>>>> *Cc:* Fabien Imbault ; Denis < >>>>>>>>>>>>>>>> denis.ietf@free.fr>; GNAP Mailing List ; >>>>>>>>>>>>>>>> Justin Richer >>>>>>>>>>>>>>>> *Subject:* Re: [GNAP] Review of >>>>>>>>>>>>>>>> draft-ietf-gnap-core-protocol-00 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Got it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So web apps invoke a openid: deep link and hope there is a= n >>>>>>>>>>>>>>>> app to handle the openid: scheme? ... and that it is the u= ser's wallet >>>>>>>>>>>>>>>> rather than some malware that has registered openid: on th= e mobile device? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A native app can attempt to open a deep link associated >>>>>>>>>>>>>>>> with an app, and will fail if the app is not there. If the= app is there, it >>>>>>>>>>>>>>>> will be opened, so this can't be used to silently test if = an app is >>>>>>>>>>>>>>>> present, but it does allow a native app to provide an alte= rnative >>>>>>>>>>>>>>>> experience if an app is not present. I don't think this wo= rks with custom >>>>>>>>>>>>>>>> schemes ... and I don't know how it could work from a web = app on the phone >>>>>>>>>>>>>>>> with the current Safari APIs. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Apple warns against using custom schemes [1] ... but >>>>>>>>>>>>>>>> perhaps they can be convinced to make openid: a managed sc= heme similar to >>>>>>>>>>>>>>>> mailto:, tel:, sms:, facetime: ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>> https://developer.apple.com/documentation/xcode/allowing_a= pps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_y= our_app >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>>>>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You are - that is not standard which is opeind:// >>>>>>>>>>>>>>>> This is the one step that still needs to be optimized for >>>>>>>>>>>>>>>> SIOP to have good UX. >>>>>>>>>>>>>>>> Peace ..tom >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt < >>>>>>>>>>>>>>>> dick.hardt@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Tom >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I watched your video (I watched at 2X speed) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Looks like the employment website app that is using >>>>>>>>>>>>>>>> localhost:8765 to communicate with the wallet. Am I correc= t? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Dick >>>>>>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones < >>>>>>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Well, here's a demo. Note that in this case the AS is not >>>>>>>>>>>>>>>> online all of the time, so it is really implicit flow and = the OIDC id-token >>>>>>>>>>>>>>>> comes from the siop device directly. >>>>>>>>>>>>>>>> (whether this is front-channel or back channel is no longe= r >>>>>>>>>>>>>>>> an interesting question.) >>>>>>>>>>>>>>>> Now if an always-on AS is required, that is possible, but >>>>>>>>>>>>>>>> probably beyond the scope of this effort and would require= something like >>>>>>>>>>>>>>>> an agent-in-the-sky (with diamonds). >>>>>>>>>>>>>>>> here is the link to the 9 min video https://youtu.be >>>>>>>>>>>>>>>> /Tq4hw7X5SW0 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Peace ..tom >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer < >>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ultimately, in most situations like these in the real >>>>>>>>>>>>>>>> world, the hurdle isn=E2=80=99t technical compatibility so= much as it is trust >>>>>>>>>>>>>>>> compatibility. The RP (client) needs to have some incentiv= e to trust the >>>>>>>>>>>>>>>> assertions and identity information that=E2=80=99s coming = from the AS. The same is >>>>>>>>>>>>>>>> true for an RS trusting tokens from the AS. The hard quest= ion is less =E2=80=9Chow=E2=80=9D >>>>>>>>>>>>>>>> to do that (which SSI answers), but more =E2=80=9Cwhy=E2= =80=9D to do that (which SSI >>>>>>>>>>>>>>>> doesn=E2=80=99t answer very well, because it=E2=80=99s a h= ard question). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Still: it=E2=80=99s definitely a question about how to sup= port this >>>>>>>>>>>>>>>> =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got = the start of it more than OAuth2/OIDC >>>>>>>>>>>>>>>> have by allowing the bootstrap of the process from a start= ing call: the >>>>>>>>>>>>>>>> interaction and continuation URIs handed back by the AS do= n=E2=80=99t need to be >>>>>>>>>>>>>>>> the same URIs that the client starts with, so just like SI= OP the process >>>>>>>>>>>>>>>> can start in HTTP and potentially move to other communicat= ion channels. A >>>>>>>>>>>>>>>> major difference is that we aren=E2=80=99t dependent on th= e assumption that the >>>>>>>>>>>>>>>> user will always be in a browser at some stage, and so the= whole raft of >>>>>>>>>>>>>>>> front-channel messages that SIOP relies on doesn=E2=80=99t= fly. That said, we=E2=80=99ve >>>>>>>>>>>>>>>> got an opportunity to more explicitly open up alternative = communication >>>>>>>>>>>>>>>> channels here, and that=E2=80=99s something I=E2=80=99d li= ke to see engineered, even if >>>>>>>>>>>>>>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concr= ete proposal as to how that would >>>>>>>>>>>>>>>> work over specific protocols, starting with what we=E2=80= =99ve got today. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault < >>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Denis, hi Francis, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> At some point integration with SSI (on the authentication >>>>>>>>>>>>>>>> side) will probably occur, including amongst other possibi= lities SIOP >>>>>>>>>>>>>>>> (since they work with OpenID a part of the work will proba= bly be made >>>>>>>>>>>>>>>> easier). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That being said, Denis is right. It's not an AS. >>>>>>>>>>>>>>>> Technically it's entirely possible to rely on a decentrali= zed wallet (for >>>>>>>>>>>>>>>> instance on your phone) and a centralized AS. I know of a = few studies on >>>>>>>>>>>>>>>> how to decentralize the AS itself (for instance >>>>>>>>>>>>>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentral= ized-02 >>>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>>> Maybe it exists, but I'm still looking for real scenarios >>>>>>>>>>>>>>>> (or even architectures) where an AS is deployed directly o= n a phone, and >>>>>>>>>>>>>>>> under the sole authority of the RO, while being compatible= with the rest of >>>>>>>>>>>>>>>> the world. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello Francis, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> See two comments in line. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> B) Current Document >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Roles description shall not hold any assumption on the >>>>>>>>>>>>>>>> physical structure of the party fulfilling the roles. >>>>>>>>>>>>>>>> [FI] not sure what you mean >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [FP] for example, we assume the AS is a server! In most >>>>>>>>>>>>>>>> SSI based use cases, the AS will be running on the user de= vice. See SIOP ( >>>>>>>>>>>>>>>> https://identity.foundation/did-siop/). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I browsed through the two drafts, i.e. : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Decentralized Identifiers (DIDs) v1.0 Core >>>>>>>>>>>>>>>> architecture, data model, and representations W3C Worki= ng Draft 08 November >>>>>>>>>>>>>>>> 2020 >>>>>>>>>>>>>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. >>>>>>>>>>>>>>>> DIF Working Group Draft >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> At no place within these two documents, it is possible to >>>>>>>>>>>>>>>> imagine that "the AS will be running on the user device". >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> From section 3 of the DIF Working Group Draft: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> "Unlike the OIDC Authorization Code Flow as per >>>>>>>>>>>>>>>> [OIDC.Core], the SIOP will not return an access token to t= he RP". >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> An Identity Wallet is not an AS. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Roles: >>>>>>>>>>>>>>>> -> grant endpoint of the AS: Why is this a post request? >>>>>>>>>>>>>>>> This eliminates the chance of having user device hosted AS= (no server). >>>>>>>>>>>>>>>> [FI] what would you propose instead? >>>>>>>>>>>>>>>> Would also be interested to understand better the >>>>>>>>>>>>>>>> deployment model when there is no server. That's something= that was >>>>>>>>>>>>>>>> discussed several times but I'm still missing the underlyi= ng architecture >>>>>>>>>>>>>>>> and use case. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [FP] See above (SIOP). There will be a lot of identity >>>>>>>>>>>>>>>> wallets operated on end user device. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> See the above comment. Please, do not confuse an Identity >>>>>>>>>>>>>>>> Wallet with an Authentication Server (AS). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Denis >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it >>>>>>>>>>>>>>>> authorize the request or the access to a resource? >>>>>>>>>>>>>>>> [FI] yes, we should make the wording clearer >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Missing Section Interactions: >>>>>>>>>>>>>>>> --> This section shall introduce the notion of interaction >>>>>>>>>>>>>>>> before we start listing interaction types. >>>>>>>>>>>>>>>> [FI] yes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Interaction Types: >>>>>>>>>>>>>>>> --> I prefer a classification with Redirect, Decoupled and >>>>>>>>>>>>>>>> Embedded is. In the draft, we have one redirect and 2 deco= uple interactions >>>>>>>>>>>>>>>> and nothing else. >>>>>>>>>>>>>>>> [FI] this should be handled as a specific discussion item. >>>>>>>>>>>>>>>> As a reminder, how would you define embedded? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In practice there's at least these modes: >>>>>>>>>>>>>>>> - redirect and redirect back >>>>>>>>>>>>>>>> - redirect to different browser or device >>>>>>>>>>>>>>>> - user code >>>>>>>>>>>>>>>> - CIBA >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [FP] This classification is limited. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Redirect: same device, same or different user agents >>>>>>>>>>>>>>>> (browser, mobile app, desktop app, ...) >>>>>>>>>>>>>>>> - Decoupled: different devices >>>>>>>>>>>>>>>> - Embedded : RC carries RO authorization to AS >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Resource Access Request vs. Resource Request >>>>>>>>>>>>>>>> --> Both are mixed up. No clarification of the context of >>>>>>>>>>>>>>>> each section. >>>>>>>>>>>>>>>> [FI] could you clarify what you'd expect. Btw on this >>>>>>>>>>>>>>>> topic, there's a more general discussion on whether we sho= uld make a >>>>>>>>>>>>>>>> distinction or not. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [FP]: Here: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Resource Access Request: Requesting Access to a >>>>>>>>>>>>>>>> resource. Response is an access token (or any type of g= rant) >>>>>>>>>>>>>>>> - Resource Request: Request the resource. Response is >>>>>>>>>>>>>>>> the resource (or a corresponding execution) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Token Content Negotiation >>>>>>>>>>>>>>>> --> Not expressed as such. This is central to GNAP and not >>>>>>>>>>>>>>>> represented enough in the document. >>>>>>>>>>>>>>>> [FI] right. This should be a specific discussion item. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Requesting "User" Information >>>>>>>>>>>>>>>> we identify two types of users: RQ and RO. It will be >>>>>>>>>>>>>>>> better not to refer to a user in this draft, but either to= a RQ or an RO. >>>>>>>>>>>>>>>> [FI] yes that would avoid potential misunderstandings. >>>>>>>>>>>>>>>> Although in the end, people will translate RQ into user or= end-user most of >>>>>>>>>>>>>>>> the time. Cf in definition, currently we have Requesting >>>>>>>>>>>>>>>> Party (RQ, aka "user") >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Interaction Again >>>>>>>>>>>>>>>> -> For each interaction type, we will have to describe the >>>>>>>>>>>>>>>> protocol flow and the nature and behavior of involved Role= s (Parties), >>>>>>>>>>>>>>>> Elements, Requests. >>>>>>>>>>>>>>>> [FI] yes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [FP] Will these and into tickets? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards. >>>>>>>>>>>>>>>> /Francis >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>> TXAuth mailing list >>>>>>>>>> TXAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>> >>>>>> --0000000000006aee8a05ba9ab2c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Probably (and to be honest even for industrial users I fin= d it complex), but alternatives are not ready for prime time either.=C2=A0<= div>Maybe some day=C2=A0DIDComm could be useful as a basic block, what we s= uggest is to first use that as a potential interaction (and there's alr= eady a lot of questions that arise just from that).=C2=A0

Fabien

On Fri, Feb 5, 2021 at 6:55 PM Tom Jones <thomasclinganjones@gmail.com> = wrote:
No, you didn't misunderstand me. It's just that the ux fo= r that is not acceptable to retail users. As long as gnap sticks to industr= ial users you should do fine.

thx ..Tom (mobile)
On Fri, F= eb 5, 2021, 7:56 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
=
Targeting existing browsers and types of applications (web, = pwa, mobile, etc.) seems like a reasonable option for an industrial standar= d. Improving security, privacy, ease of use and interoperability (including= decentralized identity as well) should be good enough objectives.=C2=A0
Plus from our previous discussions, I was under the impression you = were fine with the approach of deploying the AS on the phone as a loopback,= for mobile apps. Did I miss something?

Cheers,
Fabien

Le ven. 5 f=C3=A9vr. 202= 1 =C3=A0 16:33, Tom Jones <thomasclinganjones@gmail.com>= ; a =C3=A9crit=C2=A0:
If you mean can GNAP work on old fashioned apps= running with existing browsers and existing identity providers, then yes, = i guess you are ok.

If you want to work on apps wh= ere the user is in control of authn and authz, then no, GNAP cannot work. I= t is not alone in that OIDC wont work there either.

Be the change you want to see in the wo= rld ..tom


On Fri, Feb 5, 2021 at 3:= 19 AM Fabien Imbault <fabien.imbault@gmail.com> = wrote:
Hi Tom,=C2=A0

Thanks, your responses made it clearer f= or me what you expect from an AS deployed on a mobile.=C2=A0

I think we're on the right path t= o meet the rest of your concerns. There are already a few items on these:
- privacy preserving techniques have been discussed a= nd are likely to be included (I think). It's been recognized as a core = concern=C2=A0
- not exactly sure the meaning you giv= e to discovery here (it's already been used in the WG but with a differ= ent meaning I believe). The request or the continuation api provide entry p= oints to pay attention to.=C2=A0

Is t= hat enough for your use case ? Do you need something else ? (like SSE?)

Cheers
Fabien=C2=A0

Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom J= ones <thomasclinganjones@gmail.com> a =C3=A9crit=C2= =A0:
discovery is the prime problem.=C2=A0 What causes the wallet/AS to wa= ke up and pay attention. How does the RP know what to ask for without viola= ting user privacy rights?

CHAPI would be ok i guess, but= that requires cred man to be fixed. Not sure if it fixes discovery or priv= acy even then.

= Be the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 12:45 PM Justin Richer <jricher@mit.edu> wrote:
Tom, what additional functionality do you see that= a browser would need to support in order for GNAP to be adopted? For the e= lements of the core protocol today, nothing is needed to change within the = browsers =E2=80=94 everything is built on existing functions. GNAP uses bro= wsers as a tool, and I would argue depends on them even less so than OAuth = 2 does. Extensions could use browser functionality, like using CHAPI to pas= s interaction elements, but the core protocol functions on vanilla browsers= today.

=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 3:20 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

i assumed that the wallet (aka AS) needed to be a native app, not = a PWA (which can come from a traditional web server).
There are folks, = lke Kim C, who are working on a PWA, but i agree the blocks there seem to b= e large.
THe blocks on a native app are simple, easy to describe,= and easy to ask the browser guys to fix. Not sure if they care tho.
<= div>I have trouble seeing a path to GNAP adoption for retail customers w/o = some browser support.
That's why i am mostly=C2=A0silent here= .

<= span style=3D"background-color:rgb(242,242,242);font-family:-apple-system,s= ystem-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue",&= quot;Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"= Droid Sans","Apple Color Emoji","Segoe UI Emoji",&= quot;Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-s= erif;font-size:14px;white-space:pre-wrap">Be the change you want to see in = the world ..tom


On Thu, Feb 4, 2021= at 11:43 AM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
=
Fair enough. But loopback limits a lot what you can do...= Just for debug it's a pain.=C2=A0
But as soon as you = try more, it's a bit crazy. Fun to test ipv6 (luckily supported by my I= SP) and ddns. But it feels really hacky.=C2=A0
Also = deployment is a pain, compared to a traditional webserver.=C2=A0

Le je= u. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones <thomasclinganjones@gmail.com&g= t; a =C3=A9crit=C2=A0:
doesn't work very well on windows uwp. works fi= ne on smartphones
Be the change you want = to see in the world ..tom

On Thu, F= eb 4, 2021 at 11:18 AM Justin Richer <jricher@mit.edu> wrote:
OK, thanks =E2=80=94 in = that case, there are no changes at all to GNAP, which is already HTTP drive= n. The harder parts tend to be where you can=E2=80=99t (or don=E2=80=99t wa= nt to) use something like that.

=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 2:16 PM, Tom J= ones <thomasclinganjones@gmail.com> wrote:

yes, loopback

Be the = change you want to see in the world ..tom

On Thu, Feb 4, 2021 at 11:01 AM Justin Richer <jricher@mit.edu> wrot= e:
Tom, can= you expand on how exactly the back-channel =C2=A0communication works betwe= en on-device components? Do you use HTTP locally?

Thanks= ,
=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 1:03 PM, Tom Jones <thomasclinganjones@gmail.co= m> wrote:

Justin's analysis of us= e of the front channel is misleading.
It could equally be argued that w= hat i have done is installed an AS on the phone and the communications with= it & the PR is back channel.
Basically the point is that the= old OIDC paradigms are no longer valid.
Be th= e change you want to see in the world ..tom
<= br>

On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault <fabien.imbault@gm= ail.com> wrote:
Yes, issue (#168)=C2=A0message based interaction / = DIDComm is a tentative alternative mecanism for the interaction part. Not s= ure how that would work in details=C2=A0though, prototyping will probably h= elp here.
Token delivery=C2=A0through continuation seems fine to me. Th= e client will probably have to wait for the next polling before it receives= a token issued as the result of an asynchronous interaction, but that'= s not a big issue.

But the AS on the phone seems l= ike a harder nut to crack, at least at first sight. I think that would be a= wesome, but it gives me headaches, so I think I'll work on easier stuff= right now ;-)

Fabien=C2=A0=C2=A0
<= br>
On Thu,= Feb 4, 2021 at 4:30 PM Justin Richer <jricher@mit.edu> wrote:
One of the biggest draw= backs of the current app-centric approaches in OIDC (self-issued OP, or SIO= P) is that they depend on using the front channel and browser redirects to = pass everything, which is something that GNAP is deliberately getting away = from by starting in the back channel.

That said, once a = request is kicked off in GNAP, the interaction and fulfillment can happen t= hrough any number of means. Part of the work that=E2=80=99s being done with= the =E2=80=9Cinteraction=E2=80=9D section is going to help facilitate this= , and I think that there are some other potential branches here.
=
Token delivery is where things get extra weird though =E2=80= =94 we are explicitly not delivering tokens in the front channel in the cor= e of GNAP, we=E2=80=99re using the response from the continuation API. One = idea (that isn=E2=80=99t particularly well thought out and hasn=E2=80=99t b= een implemented at all) is to have an extension declare an alternative resp= onse from the =E2=80=9Ccontinue=E2=80=9D section that=E2=80=99s defined tod= ay, which points to the GNPA continuation API. If an extension defines some= alternative way to deliver tokens, that could live alongside a continuatio= n API and the client could indicate support for it in its initial request.<= /div>

In any event, alternative interaction and delivery= methods are important, and even if we aren=E2=80=99t going to support ever= y last one of them directly, the protocol design should at least be aware o= f them.

=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 8:35 AM, Fabien Imbault <fabie= n.imbault@gmail.com> wrote:

Hi Tom,= =C2=A0

Sure, any experience on that would be greatly app= reciated, we're calling for help here (the point being that I suspect w= hat they're doing is not trivial).

Fabien

On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.c= om> wrote:
I've had such an app working for over a year. There= are issues which are being addressed by the browser Interaction team of oi= dc.

thx ..Tom (mobile)

On Thu, Feb 4, 2021, 3:12 AM Fabien= Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,=C2=A0
=
I've tried a few things with regards to using the AS on = a phone, but it's really quite=C2=A0complex.=C2=A0

=
Making that run on a phone comes with quite a bit of trouble. The most= difficult part if that we'd need to use a secure element, but just ins= talling and hosting a http server securely is not a standard setup at all. = I suggest interested people step in to work on this, as we already have a l= ot of work for the (more usual) server case and already handle a privacy pr= eserving scheme.=C2=A0

Please let us know what you= think.

Cheers,
Fabien=C2=A0
=
On Tue= , Nov 24, 2020 at 5:55 AM Fabien Imbault <fabien.imbault@gmail= .com> wrote:
Hi Francis,

I've thought a bit more to what you said. I think I'll gi= ve it a try as a separate experiment (in code, not in theory). Not that I w= ould expect it to be included in GNAP, but I kind of like the idea :-)

The direct impact for GNAP w= ould be to think about multiple ASs.=C2=A0

Will let you know.=C2=A0

Fabien=C2=A0


Le mer. 18 nov. 2020 =C3=A0 13:06, Fran= cis Pouatcha <fpo@adorsys.de> a =C3=A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"gmail-m_4815460717883467013m_4588137701409402545m_3740723253088693496m_= -99671316316621892gmail-m_4891442230495737020m_-8218552788289986907m_-85188= 15978092546954m_3550419800836567560m_-8251187544229342067m_6649396458130137= 896m_3308803089207789488m_-435436554859614529m_2888166142485750597gmail-m_7= 901394266816005280gmail-m_-6718184999452512077m_-3004232231493229381m_-8862= 550958674531306m_4552653984562635461m_387929924441527190m_66621041910038063= 85gmail-m_-542839070341023388gmail-m_-6176056956474019294gmail-m_-303716120= 2240578685gmail-m_-7520389457378808664gmail-m_-3342024782330569254m_8014700= 032835912204gmail-m_142651873244800559m_8348797445460806175LPlnk338391" rel= =3D"noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noref= errer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer nor= eferrer noreferrer noreferrer" target=3D"_blank">https://github.com/ietf-wg= -gnap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <fabien.imbault@gmai= l.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org<= /a>>; Dick Hardt <dick.hardt@gmail.com>; Tom = Jones <thomasclinganjones@gmail.com>; De= nis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@adorsys.de> wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.= com>
Cc: Fabien Imbault <fabien.imbault@gmail.com= >; Denis <denis.ietf@free.fr>; GNAP Mailing= List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <= fabien.imbault@gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentral= ized-02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <d= enis.ietf@free.fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foun= dation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= [FP]: Her= e:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txa= uth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org= /mailman/listinfo/txauth


--
TXAuth mailing list
TXAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/txauth

--0000000000006aee8a05ba9ab2c9-- From nobody Fri Feb 5 12:20:12 2021 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 E047A3A09A8 for ; Fri, 5 Feb 2021 12:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 5P-ujmNFtDQN for ; Fri, 5 Feb 2021 12:19:59 -0800 (PST) Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) (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 099073A0990 for ; Fri, 5 Feb 2021 12:19:58 -0800 (PST) Received: by mail-vs1-f43.google.com with SMTP id z3so1605371vsn.9 for ; Fri, 05 Feb 2021 12:19:58 -0800 (PST) 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=/lHiw/kLw2HKSLHmRSlIUu9gUZC1bCYwQKtGepBeggM=; b=ET9t54tDsOYcoPfaPfWYrzMQm/Fs9043emB6XjbiBAiLt51YexvCqiY+Jke0lYGQvU OTT03+2Kb426pxuq6vhSXVBfyGVNvxBfzLAIymx+o+UKOZVoRs1nNw8mBktQp1+kjiVS pqlW75A4hhg1577iaWDAGbkSif7tiRvGhL0eKLJ3eS5QlLFZhMfaw4ntzLrHf7ET4H0q yCQGnBQ8nu8Wafv8xZIjvJxvQHWTZlTg833e8Ba9oOPmwgksMbx/f9xcEr0dp9EdmYFo /ittU2gqDedQDvTxBiFtrHCfXLMxXEB7+NvxjsSuF4+kcoJx/yC53iaYNyouXda+rVKb Lr+A== X-Gm-Message-State: AOAM532x5OSA946lJan3CWoUBwnXpyLO3zteZEt+cYz+9zjjyJloYKxK VEK5RdmNLyvN9bbuiuylZQ5kF6g+mhydbgblcTQ= X-Google-Smtp-Source: ABdhPJwTQzjrbbZ1dmTMs++rQplVQyq68Q+xbn8TmYCGVSGMm6jWd62VSG9gg6afZ2DwPMaeX7jUZngZjw635PcFxdw= X-Received: by 2002:a67:e095:: with SMTP id f21mr5252695vsl.20.1612556397640; Fri, 05 Feb 2021 12:19:57 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> <77D1AE7B-076F-4095-8FAA-7C35D74614BD@mit.edu> In-Reply-To: From: Adrian Gropper Date: Fri, 5 Feb 2021 15:19:45 -0500 Message-ID: To: Fabien Imbault Cc: Tom Jones , txauth gnap , Justin Richer Content-Type: multipart/alternative; boundary="00000000000042fdec05ba9c8bcb" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 20:20:07 -0000 --00000000000042fdec05ba9c8bcb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are privacy implications as well as the cost of processing spam. A service endpoint associated with a DID can be presumed to be a public broadcast. Any party can attempt to send a message or an authorization request to that service endpoint. The operator of that service, typically the DID controller, will bear the cost and risk of processing the message. They may request a bond be posted by the party responding to the "broadcast" in order to mitigate spam and phishing. They may also require that the party seeking to communicate offer credentials, which poses a privacy risk to that party in the form of phishing "broadcasts" via DIDs and lures that lead to DIDs. In my role as invited expert on privacy to some W3C WGs and, to some extent, DIF WGs, I have not managed to understand the privacy engineering and implications in DIDcomm. I will try harder if DIDcomm has an essential role with GNAP and I can understand it in the self-sovereign or fiduciary authorization server context. Does it? Adrian On Fri, Feb 5, 2021 at 1:08 PM Fabien Imbault wrote: > Probably (and to be honest even for industrial users I find it complex), > but alternatives are not ready for prime time either. > Maybe some day DIDComm could be useful as a basic block, what we suggest > is to first use that as a potential interaction (and there's already a lo= t > of questions that arise just from that). > > Fabien > > On Fri, Feb 5, 2021 at 6:55 PM Tom Jones > wrote: > >> No, you didn't misunderstand me. It's just that the ux for that is not >> acceptable to retail users. As long as gnap sticks to industrial users y= ou >> should do fine. >> >> thx ..Tom (mobile) >> >> On Fri, Feb 5, 2021, 7:56 AM Fabien Imbault >> wrote: >> >>> Targeting existing browsers and types of applications (web, pwa, mobile= , >>> etc.) seems like a reasonable option for an industrial standard. Improv= ing >>> security, privacy, ease of use and interoperability (including >>> decentralized identity as well) should be good enough objectives. >>> Plus from our previous discussions, I was under the impression you were >>> fine with the approach of deploying the AS on the phone as a loopback, = for >>> mobile apps. Did I miss something? >>> >>> Cheers, >>> Fabien >>> >>> Le ven. 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones >>> a =C3=A9crit : >>> >>>> If you mean can GNAP work on old fashioned apps running with existing >>>> browsers and existing identity providers, then yes, i guess you are ok= . >>>> >>>> If you want to work on apps where the user is in control of authn and >>>> authz, then no, GNAP cannot work. It is not alone in that OIDC wont wo= rk >>>> there either. >>>> >>>> Be the change you want to see in the world ..tom >>>> >>>> >>>> On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault >>>> wrote: >>>> >>>>> Hi Tom, >>>>> >>>>> Thanks, your responses made it clearer for me what you expect from an >>>>> AS deployed on a mobile. >>>>> >>>>> I think we're on the right path to meet the rest of your concerns. >>>>> There are already a few items on these: >>>>> - privacy preserving techniques have been discussed and are likely to >>>>> be included (I think). It's been recognized as a core concern >>>>> - not exactly sure the meaning you give to discovery here (it's >>>>> already been used in the WG but with a different meaning I believe). = The >>>>> request or the continuation api provide entry points to pay attention= to. >>>>> >>>>> Is that enough for your use case ? Do you need something else ? (like >>>>> SSE?) >>>>> >>>>> Cheers >>>>> Fabien >>>>> >>>>> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom Jones >>>>> a =C3=A9crit : >>>>> >>>>>> discovery is the prime problem. What causes the wallet/AS to wake u= p >>>>>> and pay attention. How does the RP know what to ask for without viol= ating >>>>>> user privacy rights? >>>>>> >>>>>> CHAPI would be ok i guess, but that requires cred man to be fixed. >>>>>> Not sure if it fixes discovery or privacy even then. >>>>>> >>>>>> Be the change you want to see in the world ..tom >>>>>> >>>>>> >>>>>> On Thu, Feb 4, 2021 at 12:45 PM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> Tom, what additional functionality do you see that a browser would >>>>>>> need to support in order for GNAP to be adopted? For the elements o= f the >>>>>>> core protocol today, nothing is needed to change within the browser= s =E2=80=94 >>>>>>> everything is built on existing functions. GNAP uses browsers as a = tool, >>>>>>> and I would argue depends on them even less so than OAuth 2 does. >>>>>>> Extensions could use browser functionality, like using CHAPI to pas= s >>>>>>> interaction elements, but the core protocol functions on vanilla br= owsers >>>>>>> today. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Feb 4, 2021, at 3:20 PM, Tom Jones >>>>>>> wrote: >>>>>>> >>>>>>> i assumed that the wallet (aka AS) needed to be a native app, not a >>>>>>> PWA (which can come from a traditional web server). >>>>>>> There are folks, lke Kim C, who are working on a PWA, but i agree >>>>>>> the blocks there seem to be large. >>>>>>> THe blocks on a native app are simple, easy to describe, and easy t= o >>>>>>> ask the browser guys to fix. Not sure if they care tho. >>>>>>> I have trouble seeing a path to GNAP adoption for retail customers >>>>>>> w/o some browser support. >>>>>>> That's why i am mostly silent here. >>>>>>> >>>>>>> Be the change you want to see in the world ..tom >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Fair enough. But loopback limits a lot what you can do... Just for >>>>>>>> debug it's a pain. >>>>>>>> But as soon as you try more, it's a bit crazy. Fun to test ipv6 >>>>>>>> (luckily supported by my ISP) and ddns. But it feels really hacky. >>>>>>>> Also deployment is a pain, compared to a traditional webserver. >>>>>>>> >>>>>>>> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones < >>>>>>>> thomasclinganjones@gmail.com> a =C3=A9crit : >>>>>>>> >>>>>>>>> doesn't work very well on windows uwp. works fine on smartphones >>>>>>>>> Be the change you want to see in the world ..tom >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Feb 4, 2021 at 11:18 AM Justin Richer >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> OK, thanks =E2=80=94 in that case, there are no changes at all t= o GNAP, >>>>>>>>>> which is already HTTP driven. The harder parts tend to be where = you can=E2=80=99t >>>>>>>>>> (or don=E2=80=99t want to) use something like that. >>>>>>>>>> >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>> >>>>>>>>>> On Feb 4, 2021, at 2:16 PM, Tom Jones < >>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> yes, loopback >>>>>>>>>> >>>>>>>>>> Be the change you want to see in the world ..tom >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Feb 4, 2021 at 11:01 AM Justin Richer >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Tom, can you expand on how exactly the back-channel >>>>>>>>>>> communication works between on-device components? Do you use H= TTP locally? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>> >>>>>>>>>>> On Feb 4, 2021, at 1:03 PM, Tom Jones < >>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Justin's analysis of use of the front channel is misleading. >>>>>>>>>>> It could equally be argued that what i have done is installed a= n >>>>>>>>>>> AS on the phone and the communications with it & the PR is back= channel. >>>>>>>>>>> Basically the point is that the old OIDC paradigms are no longe= r >>>>>>>>>>> valid. >>>>>>>>>>> Be the change you want to see in the world ..tom >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault < >>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Yes, issue (#168) message based interaction / DIDComm is a >>>>>>>>>>>> tentative alternative mecanism for the interaction part. Not s= ure how that >>>>>>>>>>>> would work in details though, prototyping will probably help h= ere. >>>>>>>>>>>> Token delivery through continuation seems fine to me. The >>>>>>>>>>>> client will probably have to wait for the next polling before = it receives a >>>>>>>>>>>> token issued as the result of an asynchronous interaction, but= that's not a >>>>>>>>>>>> big issue. >>>>>>>>>>>> >>>>>>>>>>>> But the AS on the phone seems like a harder nut to crack, at >>>>>>>>>>>> least at first sight. I think that would be awesome, but it gi= ves me >>>>>>>>>>>> headaches, so I think I'll work on easier stuff right now ;-) >>>>>>>>>>>> >>>>>>>>>>>> Fabien >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> One of the biggest drawbacks of the current app-centric >>>>>>>>>>>>> approaches in OIDC (self-issued OP, or SIOP) is that they dep= end on using >>>>>>>>>>>>> the front channel and browser redirects to pass everything, w= hich is >>>>>>>>>>>>> something that GNAP is deliberately getting away from by star= ting in the >>>>>>>>>>>>> back channel. >>>>>>>>>>>>> >>>>>>>>>>>>> That said, once a request is kicked off in GNAP, the >>>>>>>>>>>>> interaction and fulfillment can happen through any number of = means. Part of >>>>>>>>>>>>> the work that=E2=80=99s being done with the =E2=80=9Cinteract= ion=E2=80=9D section is going to help >>>>>>>>>>>>> facilitate this, and I think that there are some other potent= ial branches >>>>>>>>>>>>> here. >>>>>>>>>>>>> >>>>>>>>>>>>> Token delivery is where things get extra weird though =E2=80= =94 we are >>>>>>>>>>>>> explicitly not delivering tokens in the front channel in the = core of GNAP, >>>>>>>>>>>>> we=E2=80=99re using the response from the continuation API. O= ne idea (that isn=E2=80=99t >>>>>>>>>>>>> particularly well thought out and hasn=E2=80=99t been impleme= nted at all) is to >>>>>>>>>>>>> have an extension declare an alternative response from the = =E2=80=9Ccontinue=E2=80=9D >>>>>>>>>>>>> section that=E2=80=99s defined today, which points to the GNP= A continuation API. If >>>>>>>>>>>>> an extension defines some alternative way to deliver tokens, = that could >>>>>>>>>>>>> live alongside a continuation API and the client could indica= te support for >>>>>>>>>>>>> it in its initial request. >>>>>>>>>>>>> >>>>>>>>>>>>> In any event, alternative interaction and delivery methods ar= e >>>>>>>>>>>>> important, and even if we aren=E2=80=99t going to support eve= ry last one of them >>>>>>>>>>>>> directly, the protocol design should at least be aware of the= m. >>>>>>>>>>>>> >>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault < >>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Tom, >>>>>>>>>>>>> >>>>>>>>>>>>> Sure, any experience on that would be greatly appreciated, >>>>>>>>>>>>> we're calling for help here (the point being that I suspect w= hat they're >>>>>>>>>>>>> doing is not trivial). >>>>>>>>>>>>> >>>>>>>>>>>>> Fabien >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones < >>>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I've had such an app working for over a year. There are >>>>>>>>>>>>>> issues which are being addressed by the browser Interaction = team of oidc. >>>>>>>>>>>>>> >>>>>>>>>>>>>> thx ..Tom (mobile) >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault < >>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Francis, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've tried a few things with regards to using the AS on a >>>>>>>>>>>>>>> phone, but it's really quite complex. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Making that run on a phone comes with quite a bit of >>>>>>>>>>>>>>> trouble. The most difficult part if that we'd need to use a= secure element, >>>>>>>>>>>>>>> but just installing and hosting a http server securely is n= ot a standard >>>>>>>>>>>>>>> setup at all. I suggest interested people step in to work o= n this, as we >>>>>>>>>>>>>>> already have a lot of work for the (more usual) server case= and already >>>>>>>>>>>>>>> handle a privacy preserving scheme. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please let us know what you think. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault < >>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Francis, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've thought a bit more to what you said. I think I'll giv= e >>>>>>>>>>>>>>>> it a try as a separate experiment (in code, not in theory)= . Not that I >>>>>>>>>>>>>>>> would expect it to be included in GNAP, but I kind of like= the idea :-) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The direct impact for GNAP would be to think about multipl= e >>>>>>>>>>>>>>>> ASs. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Will let you know. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha < >>>>>>>>>>>>>>>> fpo@adorsys.de> a =C3=A9crit : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It would be nice if the protocol was designed at many >>>>>>>>>>>>>>>>> layers of abstraction. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - The first layer shall design abstract protocol >>>>>>>>>>>>>>>>> flows, without specification of the mode and mechanism= of interaction. >>>>>>>>>>>>>>>>> - The second layer can instantiate the first layer for >>>>>>>>>>>>>>>>> dedicated interaction. Here we can talk http, we can d= efine interactions >>>>>>>>>>>>>>>>> that presume server based token generation, we can def= ine interaction that >>>>>>>>>>>>>>>>> run on user device based token generation. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This is also the fundament of the structure I proposed fo= r >>>>>>>>>>>>>>>>> the spec ( >>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues= /30 >>>>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /Francis >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>>>>> *From:* Fabien Imbault >>>>>>>>>>>>>>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>>>>>>>>>>>>>>> *To:* Francis Pouatcha >>>>>>>>>>>>>>>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>>>>>>>>>>>>>>> dick.hardt@gmail.com>; Tom Jones < >>>>>>>>>>>>>>>>> thomasclinganjones@gmail.com>; Denis = ; >>>>>>>>>>>>>>>>> Justin Richer >>>>>>>>>>>>>>>>> *Subject:* Re: [GNAP] Review of >>>>>>>>>>>>>>>>> draft-ietf-gnap-core-protocol-00 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Would make sense, but not so easy as we rely heavily on >>>>>>>>>>>>>>>>> HTTP. Hence the discussion about deep links and so on. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> An alternative might be provided by wasm/wasi (running a >>>>>>>>>>>>>>>>> local sandbox on your phone, for your own AS), but it's r= eally early stage. >>>>>>>>>>>>>>>>> This also poses another question that Denis has put forwa= rd, i.e. how do we >>>>>>>>>>>>>>>>> handle the multiple AS scenario (likely to occur then). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha < >>>>>>>>>>>>>>>>> fpo@adorsys.de> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We are drifting away from the original problem space. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - My original mention was about the "POST" request, >>>>>>>>>>>>>>>>> that subsumes that the "AS" is a "Server". Designing a= new protocol, we >>>>>>>>>>>>>>>>> cannot afford this limitation. >>>>>>>>>>>>>>>>> - I just mentioned SIOP to show a known and closed >>>>>>>>>>>>>>>>> example? Let us not focus on the device local discover= y scheme (like >>>>>>>>>>>>>>>>> openid:) for now. >>>>>>>>>>>>>>>>> - As capability of holding private keys on user device >>>>>>>>>>>>>>>>> evolves, server-based issuing of token will be fading = out giving way to >>>>>>>>>>>>>>>>> device local generation of token. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> While designing GNAP, let us assume the AS-Role can be >>>>>>>>>>>>>>>>> exercised on a user device and design the protocol to hon= or that. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>> /Francis >>>>>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>>>>> *From:* TXAuth on behalf of >>>>>>>>>>>>>>>>> Dick Hardt >>>>>>>>>>>>>>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>>>>>>>>>>>>>>> *To:* Tom Jones >>>>>>>>>>>>>>>>> *Cc:* Fabien Imbault ; Denis < >>>>>>>>>>>>>>>>> denis.ietf@free.fr>; GNAP Mailing List ; >>>>>>>>>>>>>>>>> Justin Richer >>>>>>>>>>>>>>>>> *Subject:* Re: [GNAP] Review of >>>>>>>>>>>>>>>>> draft-ietf-gnap-core-protocol-00 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Got it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So web apps invoke a openid: deep link and hope there is >>>>>>>>>>>>>>>>> an app to handle the openid: scheme? ... and that it is t= he user's wallet >>>>>>>>>>>>>>>>> rather than some malware that has registered openid: on t= he mobile device? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> A native app can attempt to open a deep link associated >>>>>>>>>>>>>>>>> with an app, and will fail if the app is not there. If th= e app is there, it >>>>>>>>>>>>>>>>> will be opened, so this can't be used to silently test if= an app is >>>>>>>>>>>>>>>>> present, but it does allow a native app to provide an alt= ernative >>>>>>>>>>>>>>>>> experience if an app is not present. I don't think this w= orks with custom >>>>>>>>>>>>>>>>> schemes ... and I don't know how it could work from a web= app on the phone >>>>>>>>>>>>>>>>> with the current Safari APIs. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Apple warns against using custom schemes [1] ... but >>>>>>>>>>>>>>>>> perhaps they can be convinced to make openid: a managed s= cheme similar to >>>>>>>>>>>>>>>>> mailto:, tel:, sms:, facetime: ? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>> https://developer.apple.com/documentation/xcode/allowing_= apps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_= your_app >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>>>>>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> You are - that is not standard which is opeind:// >>>>>>>>>>>>>>>>> This is the one step that still needs to be optimized for >>>>>>>>>>>>>>>>> SIOP to have good UX. >>>>>>>>>>>>>>>>> Peace ..tom >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt < >>>>>>>>>>>>>>>>> dick.hardt@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Tom >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I watched your video (I watched at 2X speed) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Looks like the employment website app that is using >>>>>>>>>>>>>>>>> localhost:8765 to communicate with the wallet. Am I corre= ct? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /Dick >>>>>>>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones < >>>>>>>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Well, here's a demo. Note that in this case the AS is not >>>>>>>>>>>>>>>>> online all of the time, so it is really implicit flow and= the OIDC id-token >>>>>>>>>>>>>>>>> comes from the siop device directly. >>>>>>>>>>>>>>>>> (whether this is front-channel or back channel is no >>>>>>>>>>>>>>>>> longer an interesting question.) >>>>>>>>>>>>>>>>> Now if an always-on AS is required, that is possible, but >>>>>>>>>>>>>>>>> probably beyond the scope of this effort and would requir= e something like >>>>>>>>>>>>>>>>> an agent-in-the-sky (with diamonds). >>>>>>>>>>>>>>>>> here is the link to the 9 min video https://youtu.be >>>>>>>>>>>>>>>>> /Tq4hw7X5SW0 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Peace ..tom >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer < >>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Ultimately, in most situations like these in the real >>>>>>>>>>>>>>>>> world, the hurdle isn=E2=80=99t technical compatibility s= o much as it is trust >>>>>>>>>>>>>>>>> compatibility. The RP (client) needs to have some incenti= ve to trust the >>>>>>>>>>>>>>>>> assertions and identity information that=E2=80=99s coming= from the AS. The same is >>>>>>>>>>>>>>>>> true for an RS trusting tokens from the AS. The hard ques= tion is less =E2=80=9Chow=E2=80=9D >>>>>>>>>>>>>>>>> to do that (which SSI answers), but more =E2=80=9Cwhy=E2= =80=9D to do that (which SSI >>>>>>>>>>>>>>>>> doesn=E2=80=99t answer very well, because it=E2=80=99s a = hard question). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Still: it=E2=80=99s definitely a question about how to su= pport >>>>>>>>>>>>>>>>> this =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99v= e got the start of it more than >>>>>>>>>>>>>>>>> OAuth2/OIDC have by allowing the bootstrap of the process= from a starting >>>>>>>>>>>>>>>>> call: the interaction and continuation URIs handed back b= y the AS don=E2=80=99t >>>>>>>>>>>>>>>>> need to be the same URIs that the client starts with, so = just like SIOP the >>>>>>>>>>>>>>>>> process can start in HTTP and potentially move to other c= ommunication >>>>>>>>>>>>>>>>> channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption >>>>>>>>>>>>>>>>> that the user will always be in a browser at some stage, = and so the whole >>>>>>>>>>>>>>>>> raft of front-channel messages that SIOP relies on doesn= =E2=80=99t fly. That said, >>>>>>>>>>>>>>>>> we=E2=80=99ve got an opportunity to more explicitly open = up alternative >>>>>>>>>>>>>>>>> communication channels here, and that=E2=80=99s something= I=E2=80=99d like to see >>>>>>>>>>>>>>>>> engineered, even if it=E2=80=99s an extension. I=E2=80=99= d love to see a concrete proposal >>>>>>>>>>>>>>>>> as to how that would work over specific protocols, starti= ng with what we=E2=80=99ve >>>>>>>>>>>>>>>>> got today. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault < >>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Denis, hi Francis, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> At some point integration with SSI (on the authentication >>>>>>>>>>>>>>>>> side) will probably occur, including amongst other possib= ilities SIOP >>>>>>>>>>>>>>>>> (since they work with OpenID a part of the work will prob= ably be made >>>>>>>>>>>>>>>>> easier). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> That being said, Denis is right. It's not an AS. >>>>>>>>>>>>>>>>> Technically it's entirely possible to rely on a decentral= ized wallet (for >>>>>>>>>>>>>>>>> instance on your phone) and a centralized AS. I know of a= few studies on >>>>>>>>>>>>>>>>> how to decentralize the AS itself (for instance >>>>>>>>>>>>>>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentra= lized-02 >>>>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>>>> Maybe it exists, but I'm still looking for real scenarios >>>>>>>>>>>>>>>>> (or even architectures) where an AS is deployed directly = on a phone, and >>>>>>>>>>>>>>>>> under the sole authority of the RO, while being compatibl= e with the rest of >>>>>>>>>>>>>>>>> the world. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello Francis, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> See two comments in line. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> B) Current Document >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Roles description shall not hold any assumption on the >>>>>>>>>>>>>>>>> physical structure of the party fulfilling the roles. >>>>>>>>>>>>>>>>> [FI] not sure what you mean >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [FP] for example, we assume the AS is a server! In most >>>>>>>>>>>>>>>>> SSI based use cases, the AS will be running on the user d= evice. See SIOP ( >>>>>>>>>>>>>>>>> https://identity.foundation/did-siop/). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I browsed through the two drafts, i.e. : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - Decentralized Identifiers (DIDs) v1.0 Core >>>>>>>>>>>>>>>>> architecture, data model, and representations W3C Work= ing Draft 08 November >>>>>>>>>>>>>>>>> 2020 >>>>>>>>>>>>>>>>> - Self-Issued OpenID Connect Provider DID Profile >>>>>>>>>>>>>>>>> v0.1. DIF Working Group Draft >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> At no place within these two documents, it is possible to >>>>>>>>>>>>>>>>> imagine that "the AS will be running on the user device". >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> From section 3 of the DIF Working Group Draft: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "Unlike the OIDC Authorization Code Flow as per >>>>>>>>>>>>>>>>> [OIDC.Core], the SIOP will not return an access token to = the RP". >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> An Identity Wallet is not an AS. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Roles: >>>>>>>>>>>>>>>>> -> grant endpoint of the AS: Why is this a post request? >>>>>>>>>>>>>>>>> This eliminates the chance of having user device hosted A= S (no server). >>>>>>>>>>>>>>>>> [FI] what would you propose instead? >>>>>>>>>>>>>>>>> Would also be interested to understand better the >>>>>>>>>>>>>>>>> deployment model when there is no server. That's somethin= g that was >>>>>>>>>>>>>>>>> discussed several times but I'm still missing the underly= ing architecture >>>>>>>>>>>>>>>>> and use case. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [FP] See above (SIOP). There will be a lot of identity >>>>>>>>>>>>>>>>> wallets operated on end user device. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> See the above comment. Please, do not confuse an Identity >>>>>>>>>>>>>>>>> Wallet with an Authentication Server (AS). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Denis >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it >>>>>>>>>>>>>>>>> authorize the request or the access to a resource? >>>>>>>>>>>>>>>>> [FI] yes, we should make the wording clearer >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Missing Section Interactions: >>>>>>>>>>>>>>>>> --> This section shall introduce the notion of interactio= n >>>>>>>>>>>>>>>>> before we start listing interaction types. >>>>>>>>>>>>>>>>> [FI] yes >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Interaction Types: >>>>>>>>>>>>>>>>> --> I prefer a classification with Redirect, Decoupled an= d >>>>>>>>>>>>>>>>> Embedded is. In the draft, we have one redirect and 2 dec= ouple interactions >>>>>>>>>>>>>>>>> and nothing else. >>>>>>>>>>>>>>>>> [FI] this should be handled as a specific discussion item= . >>>>>>>>>>>>>>>>> As a reminder, how would you define embedded? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In practice there's at least these modes: >>>>>>>>>>>>>>>>> - redirect and redirect back >>>>>>>>>>>>>>>>> - redirect to different browser or device >>>>>>>>>>>>>>>>> - user code >>>>>>>>>>>>>>>>> - CIBA >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [FP] This classification is limited. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - Redirect: same device, same or different user agents >>>>>>>>>>>>>>>>> (browser, mobile app, desktop app, ...) >>>>>>>>>>>>>>>>> - Decoupled: different devices >>>>>>>>>>>>>>>>> - Embedded : RC carries RO authorization to AS >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Resource Access Request vs. Resource Request >>>>>>>>>>>>>>>>> --> Both are mixed up. No clarification of the context of >>>>>>>>>>>>>>>>> each section. >>>>>>>>>>>>>>>>> [FI] could you clarify what you'd expect. Btw on this >>>>>>>>>>>>>>>>> topic, there's a more general discussion on whether we sh= ould make a >>>>>>>>>>>>>>>>> distinction or not. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [FP]: Here: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - Resource Access Request: Requesting Access to a >>>>>>>>>>>>>>>>> resource. Response is an access token (or any type of = grant) >>>>>>>>>>>>>>>>> - Resource Request: Request the resource. Response is >>>>>>>>>>>>>>>>> the resource (or a corresponding execution) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Token Content Negotiation >>>>>>>>>>>>>>>>> --> Not expressed as such. This is central to GNAP and no= t >>>>>>>>>>>>>>>>> represented enough in the document. >>>>>>>>>>>>>>>>> [FI] right. This should be a specific discussion item. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Requesting "User" Information >>>>>>>>>>>>>>>>> we identify two types of users: RQ and RO. It will be >>>>>>>>>>>>>>>>> better not to refer to a user in this draft, but either t= o a RQ or an RO. >>>>>>>>>>>>>>>>> [FI] yes that would avoid potential misunderstandings. >>>>>>>>>>>>>>>>> Although in the end, people will translate RQ into user o= r end-user most of >>>>>>>>>>>>>>>>> the time. Cf in definition, currently we have Requesting >>>>>>>>>>>>>>>>> Party (RQ, aka "user") >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Interaction Again >>>>>>>>>>>>>>>>> -> For each interaction type, we will have to describe th= e >>>>>>>>>>>>>>>>> protocol flow and the nature and behavior of involved Rol= es (Parties), >>>>>>>>>>>>>>>>> Elements, Requests. >>>>>>>>>>>>>>>>> [FI] yes >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [FP] Will these and into tickets? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards. >>>>>>>>>>>>>>>>> /Francis >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>> TXAuth mailing list >>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> TXAuth mailing list >>>>>>>>> TXAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>> >>>>>>>> >>>>>>> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000042fdec05ba9c8bcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are privacy implications as well as the cost of proc= essing spam. A service endpoint associated with a DID can be presumed to be= a public broadcast. Any party can attempt to send a message or an authoriz= ation request to that service endpoint. The operator of that service, typic= ally the DID controller, will bear the cost and risk of processing the mess= age. They may request a bond be posted by the party responding to the "= ;broadcast" in order to mitigate spam and phishing. They may also requ= ire that the party seeking to communicate offer credentials, which poses a = privacy risk to that party in the form of phishing "broadcasts" v= ia DIDs and lures that lead to DIDs.=C2=A0

In my role as= invited expert on privacy to some W3C WGs and, to some extent, DIF WGs, I = have not managed to understand the privacy engineering and implications in = DIDcomm. I will try harder if DIDcomm has an essential role with GNAP and I= can understand it in the self-sovereign or fiduciary authorization server = context. Does it?

Adrian

On Fri, Feb 5, 2021 = at 1:08 PM Fabien Imbault <f= abien.imbault@gmail.com> wrote:
Probably (and to be honest even for industrial users I find it com= plex), but alternatives are not ready for prime time either.=C2=A0
Mayb= e some day=C2=A0DIDComm could be useful as a basic block, what we suggest i= s to first use that as a potential interaction (and there's already a l= ot of questions that arise just from that).=C2=A0

= Fabien

On Fri, Feb 5, 2021 at 6:55 PM Tom Jones <thomasclinganjones@gmail.co= m> wrote:
No, you didn&#= 39;t misunderstand me. It's just that the ux for that is not acceptable= to retail users. As long as gnap sticks to industrial users you should do = fine.

thx ..Tom (mobile)

On Fri, Feb 5, 2021, 7:56 AM Fabi= en Imbault <fabien.imbault@gmail.com> wrote:
Targeting existing browsers and types of a= pplications (web, pwa, mobile, etc.) seems like a reasonable option for an = industrial standard. Improving security, privacy, ease of use and interoper= ability (including decentralized identity as well) should be good enough ob= jectives.=C2=A0
Plus from our previous discussions, I was under t= he impression you were fine with the approach of deploying the AS on the ph= one as a loopback, for mobile apps. Did I miss something?

Cheers,
Fabien

Le ven= . 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones <thomasclinganjone= s@gmail.com> a =C3=A9crit=C2=A0:
If you mean can GNAP work on old fashioned apps running with = existing browsers and existing identity providers, then yes, i guess you ar= e ok.

If you want to work on apps where the user i= s in control of authn and authz, then no, GNAP cannot work. It is not alone= in that OIDC wont work there either.

Be the change you want to see in the world ..t= om


On Fri, Feb 5, 2021 at 3:19 AM Fabien I= mbault <fabien.imbault@gmail.com> wrote:
Hi = Tom,=C2=A0

Thanks, your = responses made it clearer for me what you expect from an AS deployed on a m= obile.=C2=A0

I think we&= #39;re on the right path to meet the rest of your concerns. There are alrea= dy a few items on these:
- privacy preserving techni= ques have been discussed and are likely to be included (I think). It's = been recognized as a core concern=C2=A0
- not exactl= y sure the meaning you give to discovery here (it's already been used i= n the WG but with a different meaning I believe). The request or the contin= uation api provide entry points to pay attention to.=C2=A0

Is that enough for your use case ? Do you need someth= ing else ? (like SSE?)

C= heers
Fabien=C2=A0

Le jeu. 4 f=C3=A9vr. = 2021 =C3=A0 22:10, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit=C2=A0:
disco= very is the prime problem.=C2=A0 What causes the wallet/AS to wake up and p= ay attention. How does the RP know what to ask for without violating user p= rivacy rights?

CHAPI would be ok i guess, but that requi= res cred man to be fixed. Not sure if it fixes discovery or privacy even th= en.

<= span style=3D"background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-= family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"= Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans&= quot;,Cantarell,"Droid Sans","Apple Color Emoji","= Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",= Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">Be the chan= ge you want to see in the world ..tom


On Thu, Feb 4, 2021 at 12:45 PM Justin Richer <jriche= r@mit.edu> wrote:
Tom, what additio= nal functionality do you see that a browser would need to support in order = for GNAP to be adopted? For the elements of the core protocol today, nothin= g is needed to change within the browsers =E2=80=94 everything is built on = existing functions. GNAP uses browsers as a tool, and I would argue depends= on them even less so than OAuth 2 does. Extensions could use browser funct= ionality, like using CHAPI to pass interaction elements, but the core proto= col functions on vanilla browsers today.

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

On Feb 4, 2021, at 3:20 = PM, Tom Jones <thomasclinganjones@gmail.com&g= t; wrote:

i assumed that the wallet (aka AS)= needed to be a native app, not a PWA (which can come from a traditional we= b server).
There are folks, lke Kim C, who are working on a PWA, but i = agree the blocks there seem to be large.
THe blocks on a native a= pp are simple, easy to describe, and easy to ask the browser guys to fix. N= ot sure if they care tho.
I have trouble seeing a path to GNAP ad= option for retail customers w/o some browser support.
That's = why i am mostly=C2=A0silent here.

B= e the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
=
Fair enough. But loopback limits a lot what you can do...= Just for debug it's a pain.=C2=A0
But as soon as you = try more, it's a bit crazy. Fun to test ipv6 (luckily supported by my I= SP) and ddns. But it feels really hacky.=C2=A0
Also = deployment is a pain, compared to a traditional webserver.=C2=A0

Le je= u. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones <thomasclinganjones@gmail.com&g= t; a =C3=A9crit=C2=A0:
doesn'= ;t work very well on windows uwp. works fine on smartphones
Be the change you want to see in the world ..tom<= /div>


On Thu, Feb 4, 2021 at 11:18 AM Justin Ric= her <jr= icher@mit.edu> wrote:
OK, thanks =E2= =80=94 in that case, there are no changes at all to GNAP, which is already = HTTP driven. The harder parts tend to be where you can=E2=80=99t (or don=E2= =80=99t want to) use something like that.

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

On Feb 4, 2021, at 2:= 16 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:
yes, loopback

Be the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:01 AM Justin Richer <jricher@mit.edu<= /a>> wrote:
Tom, can you expand on how ex= actly the back-channel =C2=A0communication works between on-device componen= ts? Do you use HTTP locally?

Thanks,
=C2=A0=E2= =80=94 Justin

On Feb 4, 2021, at= 1:03 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:
Justin's analysis of use of the front channe= l is misleading.
It could equally be argued that what i have done is in= stalled an AS on the phone and the communications with it & the PR is b= ack channel.
Basically the point is that the old OIDC paradigms a= re no longer valid.
Be the change you want to = see in the world ..tom


On Thu, Feb = 4, 2021 at 7:47 AM Fabien Imbault <fabien.imbault@gmail.com> wrote= :
Yes, issue (#168)=C2=A0message= based interaction / DIDComm is a tentative alternative mecanism for the in= teraction part. Not sure how that would work in details=C2=A0though, protot= yping will probably help here.
Token delivery=C2=A0through continuation= seems fine to me. The client will probably have to wait for the next polli= ng before it receives a token issued as the result of an asynchronous inter= action, but that's not a big issue.

But the AS= on the phone seems like a harder nut to crack, at least at first sight. I = think that would be awesome, but it gives me headaches, so I think I'll= work on easier stuff right now ;-)

Fabien=C2=A0= =C2=A0

On Thu, Feb 4, 2021 at 4:30 PM Justin Richer <jricher@mit.edu&= gt; wrote:
One of the biggest drawbacks of t= he current app-centric approaches in OIDC (self-issued OP, or SIOP) is that= they depend on using the front channel and browser redirects to pass every= thing, which is something that GNAP is deliberately getting away from by st= arting in the back channel.

That said, once a request is= kicked off in GNAP, the interaction and fulfillment can happen through any= number of means. Part of the work that=E2=80=99s being done with the =E2= =80=9Cinteraction=E2=80=9D section is going to help facilitate this, and I = think that there are some other potential branches here.

Token delivery is where things get extra weird though =E2=80=94 we a= re explicitly not delivering tokens in the front channel in the core of GNA= P, we=E2=80=99re using the response from the continuation API. One idea (th= at isn=E2=80=99t particularly well thought out and hasn=E2=80=99t been impl= emented at all) is to have an extension declare an alternative response fro= m the =E2=80=9Ccontinue=E2=80=9D section that=E2=80=99s defined today, whic= h points to the GNPA continuation API. If an extension defines some alterna= tive way to deliver tokens, that could live alongside a continuation API an= d the client could indicate support for it in its initial request.

In any event, alternative interaction and delivery methods= are important, and even if we aren=E2=80=99t going to support every last o= ne of them directly, the protocol design should at least be aware of them.<= /div>

=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 8:35 AM, Fabien Imbault <fabien.imbaul= t@gmail.com> wrote:

Hi Tom,=C2=A0
Sure, any experience on that would be greatly appreciated, = we're calling for help here (the point being that I suspect what they&#= 39;re doing is not trivial).

Fabien
On Thu, F= eb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com>= wrote:
I've had such an ap= p working for over a year. There are issues which are being addressed by th= e browser Interaction team of oidc.

thx ..Tom (mobile)

On = Thu, Feb 4, 2021, 3:12 AM Fabien Imbault <fabien.imbault@gmail.com>= ; wrote:
Hi Francis,=C2=A0
<= br>
I've tried a few things with regards to using the AS on a= phone, but it's really quite=C2=A0complex.=C2=A0

<= div>Making that run on a phone comes with quite a bit of trouble. The most = difficult part if that we'd need to use a secure element, but just inst= alling and hosting a http server securely is not a standard setup at all. I= suggest interested people step in to work on this, as we already have a lo= t of work for the (more usual) server case and already handle a privacy pre= serving scheme.=C2=A0

Please let us know what you = think.

Cheers,
Fabien=C2=A0
<= br>
On Tue,= Nov 24, 2020 at 5:55 AM Fabien Imbault <fabien.imbault@gmail.= com> wrote:
Hi Fran= cis,

I've thought a bit mo= re to what you said. I think I'll give it a try as a separate experimen= t (in code, not in theory). Not that I would expect it to be included in GN= AP, but I kind of like the idea :-)

The direct impact for GNAP would be to think about multiple ASs= .=C2=A0

Will let you kno= w.=C2=A0

Fabien=C2=A0

Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha <fpo@adorsys.de= > a =C3=A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"gmail-m_2454565993824225076gmail-m_4815460717883467013m_458813770140940= 2545m_3740723253088693496m_-99671316316621892gmail-m_4891442230495737020m_-= 8218552788289986907m_-8518815978092546954m_3550419800836567560m_-8251187544= 229342067m_6649396458130137896m_3308803089207789488m_-435436554859614529m_2= 888166142485750597gmail-m_7901394266816005280gmail-m_-6718184999452512077m_= -3004232231493229381m_-8862550958674531306m_4552653984562635461m_3879299244= 41527190m_6662104191003806385gmail-m_-542839070341023388gmail-m_-6176056956= 474019294gmail-m_-3037161202240578685gmail-m_-7520389457378808664gmail-m_-3= 342024782330569254m_8014700032835912204gmail-m_142651873244800559m_83487974= 45460806175LPlnk338391" rel=3D"noreferrer noreferrer noreferrer noreferrer = noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferre= r noreferrer noreferrer noreferrer noreferrer noreferrer" target=3D"_blank"= >https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org<= /a>>; Dick Hardt <dick.hardt@gmail.com>; Tom = Jones <thomasclinganjones@gmail.com>; De= nis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@adorsys.de> wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
= From: TX= Auth <txauth-bounces@ietf.org> on behalf of D= ick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.= com>
Cc: Fabien Imbault <fabien.imbault@gmail.com= >; Denis <denis.ietf@free.fr>; GNAP Mailing= List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <= fabien.imbault@gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentral= ized-02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <d= enis.ietf@free.fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foun= dation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= [FP]: Her= e:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txa= uth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org= /mailman/listinfo/txauth


--
TXAuth mailing list
TXAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000042fdec05ba9c8bcb-- From nobody Fri Feb 5 12:42:08 2021 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 E86263A0786 for ; Fri, 5 Feb 2021 12:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 v0rW2G2pI6KM for ; Fri, 5 Feb 2021 12:42:00 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 C8D1A3A0652 for ; Fri, 5 Feb 2021 12:41:59 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id x21so8507554iog.10 for ; Fri, 05 Feb 2021 12:41:59 -0800 (PST) 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=MzGaWTxJbGT3eSE3xxLx5AEnB5LOLnxIOhfOK7C1l0c=; b=ooESRg52cCx2v9VOnUubJwrENCCstjuhjuWFyNZiuX6vh8qkTw9rZORNLJMtDXi5EK 71SV63Ao205IZOESC8fAwEWH2hu1ltYj/C2wqFnCsAD+QXB2Lk1pdLsrwNe512NUaeoZ gXK/fTkV1knrxtWh6WD11sc+V5/tJ2xhQBGK/d+UhrTra83gzcZkXC7qgLgFT04DgrvM gSDCik40U2FJv6O8m/qv9rRHW98e4FkvHePQfH8dfpXQESwzEdstGjWDazL2MoUg87Wu PZeplrfhw3nd1FWomeidhkuD/9TPK043iH2Zhcg4rnxWj+5uE8vefbgjEQY3ij8h5yQu IpXg== 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=MzGaWTxJbGT3eSE3xxLx5AEnB5LOLnxIOhfOK7C1l0c=; b=jYNQZMSv2nd4CVB9dgddwFVgzlv1x5IOrmoiK/z1hI0yVaCButBS0KDccYkx35BWIa 5EGs6HPo0QFI3xjwnO2/12CQ6PMRYgaEwTfPE7gWsGjBuj0AqJJjV386P1CCqKp09S89 ETQ/vDmudKaNg0tx6hPGtNR+oQulojL2Hsrd3gnc6x0+eRq0o/IculcSJziAEBJwjJ5R wHCZgdWKishgm/7ldVmqRUb1uGT56dZmIXXIMI2MF2SvRnJoyEJTBGJHw3Fj61QB8yII 9NkFSMEXsZVe+bkUMgXjDfYQGApUr8NWmALX1mVJUT2KI89bKwuroJJF929/lifksBAr izyQ== X-Gm-Message-State: AOAM532y6vkafTVaw5kzAXq/JpSu23/aRMt+/qcjwGCvR5PlRA3DDyV+ ffmr7dvdGt4bIfI1MPZBFfu7tdHXW6Wms4ddb90= X-Google-Smtp-Source: ABdhPJzLtQJmbeX783IriRqPs5USy7KROsHks6njoFib48y8F2xNy3mwnNcQYUjBP0p4ifJXm8DaBbrFS3Ds48BtgjU= X-Received: by 2002:a5e:8d11:: with SMTP id m17mr5558856ioj.144.1612557718909; Fri, 05 Feb 2021 12:41:58 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> <77D1AE7B-076F-4095-8FAA-7C35D74614BD@mit.edu> In-Reply-To: From: Fabien Imbault Date: Fri, 5 Feb 2021 21:41:45 +0100 Message-ID: To: Adrian Gropper Cc: Tom Jones , txauth gnap , Justin Richer Content-Type: multipart/alternative; boundary="00000000000003f5ef05ba9cdaef" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 20:42:06 -0000 --00000000000003f5ef05ba9cdaef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adrian, We would be glad to get your expertise on that. Not sure DIDComm is essential yet, so far I see it personally as something to look into, especially for use cases when we want to reach out to a RO. I agree with the potential issues. I have a few ideas on how to implement privacy, but it's quite involved in terms of crypto (again using Ristretto groups :-)). Of course there will be a question of priority in the features we plan to implement. I guess we should aim for a first publication without the parts which are blurry, and take the time to prototype the rest. Cheers Fabien Le ven. 5 f=C3=A9vr. 2021 =C3=A0 21:19, Adrian Gropper a =C3=A9crit : > There are privacy implications as well as the cost of processing spam. A > service endpoint associated with a DID can be presumed to be a public > broadcast. Any party can attempt to send a message or an authorization > request to that service endpoint. The operator of that service, typically > the DID controller, will bear the cost and risk of processing the message= . > They may request a bond be posted by the party responding to the > "broadcast" in order to mitigate spam and phishing. They may also require > that the party seeking to communicate offer credentials, which poses a > privacy risk to that party in the form of phishing "broadcasts" via DIDs > and lures that lead to DIDs. > > In my role as invited expert on privacy to some W3C WGs and, to some > extent, DIF WGs, I have not managed to understand the privacy engineering > and implications in DIDcomm. I will try harder if DIDcomm has an essentia= l > role with GNAP and I can understand it in the self-sovereign or fiduciary > authorization server context. Does it? > > Adrian > > On Fri, Feb 5, 2021 at 1:08 PM Fabien Imbault > wrote: > >> Probably (and to be honest even for industrial users I find it complex), >> but alternatives are not ready for prime time either. >> Maybe some day DIDComm could be useful as a basic block, what we suggest >> is to first use that as a potential interaction (and there's already a l= ot >> of questions that arise just from that). >> >> Fabien >> >> On Fri, Feb 5, 2021 at 6:55 PM Tom Jones >> wrote: >> >>> No, you didn't misunderstand me. It's just that the ux for that is not >>> acceptable to retail users. As long as gnap sticks to industrial users = you >>> should do fine. >>> >>> thx ..Tom (mobile) >>> >>> On Fri, Feb 5, 2021, 7:56 AM Fabien Imbault >>> wrote: >>> >>>> Targeting existing browsers and types of applications (web, pwa, >>>> mobile, etc.) seems like a reasonable option for an industrial standar= d. >>>> Improving security, privacy, ease of use and interoperability (includi= ng >>>> decentralized identity as well) should be good enough objectives. >>>> Plus from our previous discussions, I was under the impression you wer= e >>>> fine with the approach of deploying the AS on the phone as a loopback,= for >>>> mobile apps. Did I miss something? >>>> >>>> Cheers, >>>> Fabien >>>> >>>> Le ven. 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones >>>> a =C3=A9crit : >>>> >>>>> If you mean can GNAP work on old fashioned apps running with existing >>>>> browsers and existing identity providers, then yes, i guess you are o= k. >>>>> >>>>> If you want to work on apps where the user is in control of authn and >>>>> authz, then no, GNAP cannot work. It is not alone in that OIDC wont w= ork >>>>> there either. >>>>> >>>>> Be the change you want to see in the world ..tom >>>>> >>>>> >>>>> On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Tom, >>>>>> >>>>>> Thanks, your responses made it clearer for me what you expect from a= n >>>>>> AS deployed on a mobile. >>>>>> >>>>>> I think we're on the right path to meet the rest of your concerns. >>>>>> There are already a few items on these: >>>>>> - privacy preserving techniques have been discussed and are likely t= o >>>>>> be included (I think). It's been recognized as a core concern >>>>>> - not exactly sure the meaning you give to discovery here (it's >>>>>> already been used in the WG but with a different meaning I believe).= The >>>>>> request or the continuation api provide entry points to pay attentio= n to. >>>>>> >>>>>> Is that enough for your use case ? Do you need something else ? (lik= e >>>>>> SSE?) >>>>>> >>>>>> Cheers >>>>>> Fabien >>>>>> >>>>>> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom Jones >>>>>> a =C3=A9crit : >>>>>> >>>>>>> discovery is the prime problem. What causes the wallet/AS to wake >>>>>>> up and pay attention. How does the RP know what to ask for without >>>>>>> violating user privacy rights? >>>>>>> >>>>>>> CHAPI would be ok i guess, but that requires cred man to be fixed. >>>>>>> Not sure if it fixes discovery or privacy even then. >>>>>>> >>>>>>> Be the change you want to see in the world ..tom >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 4, 2021 at 12:45 PM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> Tom, what additional functionality do you see that a browser would >>>>>>>> need to support in order for GNAP to be adopted? For the elements = of the >>>>>>>> core protocol today, nothing is needed to change within the browse= rs =E2=80=94 >>>>>>>> everything is built on existing functions. GNAP uses browsers as a= tool, >>>>>>>> and I would argue depends on them even less so than OAuth 2 does. >>>>>>>> Extensions could use browser functionality, like using CHAPI to pa= ss >>>>>>>> interaction elements, but the core protocol functions on vanilla b= rowsers >>>>>>>> today. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> On Feb 4, 2021, at 3:20 PM, Tom Jones >>>>>>>> wrote: >>>>>>>> >>>>>>>> i assumed that the wallet (aka AS) needed to be a native app, not = a >>>>>>>> PWA (which can come from a traditional web server). >>>>>>>> There are folks, lke Kim C, who are working on a PWA, but i agree >>>>>>>> the blocks there seem to be large. >>>>>>>> THe blocks on a native app are simple, easy to describe, and easy >>>>>>>> to ask the browser guys to fix. Not sure if they care tho. >>>>>>>> I have trouble seeing a path to GNAP adoption for retail customers >>>>>>>> w/o some browser support. >>>>>>>> That's why i am mostly silent here. >>>>>>>> >>>>>>>> Be the change you want to see in the world ..tom >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Fair enough. But loopback limits a lot what you can do... Just fo= r >>>>>>>>> debug it's a pain. >>>>>>>>> But as soon as you try more, it's a bit crazy. Fun to test ipv6 >>>>>>>>> (luckily supported by my ISP) and ddns. But it feels really hacky= . >>>>>>>>> Also deployment is a pain, compared to a traditional webserver. >>>>>>>>> >>>>>>>>> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones < >>>>>>>>> thomasclinganjones@gmail.com> a =C3=A9crit : >>>>>>>>> >>>>>>>>>> doesn't work very well on windows uwp. works fine on smartphones >>>>>>>>>> Be the change you want to see in the world ..tom >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Feb 4, 2021 at 11:18 AM Justin Richer >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> OK, thanks =E2=80=94 in that case, there are no changes at all = to GNAP, >>>>>>>>>>> which is already HTTP driven. The harder parts tend to be where= you can=E2=80=99t >>>>>>>>>>> (or don=E2=80=99t want to) use something like that. >>>>>>>>>>> >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>> >>>>>>>>>>> On Feb 4, 2021, at 2:16 PM, Tom Jones < >>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> yes, loopback >>>>>>>>>>> >>>>>>>>>>> Be the change you want to see in the world ..tom >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Feb 4, 2021 at 11:01 AM Justin Richer >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Tom, can you expand on how exactly the back-channel >>>>>>>>>>>> communication works between on-device components? Do you use = HTTP locally? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>> >>>>>>>>>>>> On Feb 4, 2021, at 1:03 PM, Tom Jones < >>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Justin's analysis of use of the front channel is misleading. >>>>>>>>>>>> It could equally be argued that what i have done is installed >>>>>>>>>>>> an AS on the phone and the communications with it & the PR is = back channel. >>>>>>>>>>>> Basically the point is that the old OIDC paradigms are no >>>>>>>>>>>> longer valid. >>>>>>>>>>>> Be the change you want to see in the world ..tom >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault < >>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Yes, issue (#168) message based interaction / DIDComm is a >>>>>>>>>>>>> tentative alternative mecanism for the interaction part. Not = sure how that >>>>>>>>>>>>> would work in details though, prototyping will probably help = here. >>>>>>>>>>>>> Token delivery through continuation seems fine to me. The >>>>>>>>>>>>> client will probably have to wait for the next polling before= it receives a >>>>>>>>>>>>> token issued as the result of an asynchronous interaction, bu= t that's not a >>>>>>>>>>>>> big issue. >>>>>>>>>>>>> >>>>>>>>>>>>> But the AS on the phone seems like a harder nut to crack, at >>>>>>>>>>>>> least at first sight. I think that would be awesome, but it g= ives me >>>>>>>>>>>>> headaches, so I think I'll work on easier stuff right now ;-) >>>>>>>>>>>>> >>>>>>>>>>>>> Fabien >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> One of the biggest drawbacks of the current app-centric >>>>>>>>>>>>>> approaches in OIDC (self-issued OP, or SIOP) is that they de= pend on using >>>>>>>>>>>>>> the front channel and browser redirects to pass everything, = which is >>>>>>>>>>>>>> something that GNAP is deliberately getting away from by sta= rting in the >>>>>>>>>>>>>> back channel. >>>>>>>>>>>>>> >>>>>>>>>>>>>> That said, once a request is kicked off in GNAP, the >>>>>>>>>>>>>> interaction and fulfillment can happen through any number of= means. Part of >>>>>>>>>>>>>> the work that=E2=80=99s being done with the =E2=80=9Cinterac= tion=E2=80=9D section is going to help >>>>>>>>>>>>>> facilitate this, and I think that there are some other poten= tial branches >>>>>>>>>>>>>> here. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Token delivery is where things get extra weird though =E2=80= =94 we >>>>>>>>>>>>>> are explicitly not delivering tokens in the front channel in= the core of >>>>>>>>>>>>>> GNAP, we=E2=80=99re using the response from the continuation= API. One idea (that >>>>>>>>>>>>>> isn=E2=80=99t particularly well thought out and hasn=E2=80= =99t been implemented at all) is >>>>>>>>>>>>>> to have an extension declare an alternative response from th= e =E2=80=9Ccontinue=E2=80=9D >>>>>>>>>>>>>> section that=E2=80=99s defined today, which points to the GN= PA continuation API. If >>>>>>>>>>>>>> an extension defines some alternative way to deliver tokens,= that could >>>>>>>>>>>>>> live alongside a continuation API and the client could indic= ate support for >>>>>>>>>>>>>> it in its initial request. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In any event, alternative interaction and delivery methods >>>>>>>>>>>>>> are important, and even if we aren=E2=80=99t going to suppor= t every last one of >>>>>>>>>>>>>> them directly, the protocol design should at least be aware = of them. >>>>>>>>>>>>>> >>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault < >>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Tom, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sure, any experience on that would be greatly appreciated, >>>>>>>>>>>>>> we're calling for help here (the point being that I suspect = what they're >>>>>>>>>>>>>> doing is not trivial). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones < >>>>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've had such an app working for over a year. There are >>>>>>>>>>>>>>> issues which are being addressed by the browser Interaction= team of oidc. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> thx ..Tom (mobile) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault < >>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Francis, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've tried a few things with regards to using the AS on a >>>>>>>>>>>>>>>> phone, but it's really quite complex. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Making that run on a phone comes with quite a bit of >>>>>>>>>>>>>>>> trouble. The most difficult part if that we'd need to use = a secure element, >>>>>>>>>>>>>>>> but just installing and hosting a http server securely is = not a standard >>>>>>>>>>>>>>>> setup at all. I suggest interested people step in to work = on this, as we >>>>>>>>>>>>>>>> already have a lot of work for the (more usual) server cas= e and already >>>>>>>>>>>>>>>> handle a privacy preserving scheme. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please let us know what you think. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault < >>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Francis, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've thought a bit more to what you said. I think I'll >>>>>>>>>>>>>>>>> give it a try as a separate experiment (in code, not in t= heory). Not that I >>>>>>>>>>>>>>>>> would expect it to be included in GNAP, but I kind of lik= e the idea :-) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The direct impact for GNAP would be to think about >>>>>>>>>>>>>>>>> multiple ASs. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Will let you know. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha < >>>>>>>>>>>>>>>>> fpo@adorsys.de> a =C3=A9crit : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It would be nice if the protocol was designed at many >>>>>>>>>>>>>>>>>> layers of abstraction. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - The first layer shall design abstract protocol >>>>>>>>>>>>>>>>>> flows, without specification of the mode and mechanis= m of interaction. >>>>>>>>>>>>>>>>>> - The second layer can instantiate the first layer >>>>>>>>>>>>>>>>>> for dedicated interaction. Here we can talk http, we = can define >>>>>>>>>>>>>>>>>> interactions that presume server based token generati= on, we can define >>>>>>>>>>>>>>>>>> interaction that run on user device based token gener= ation. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This is also the fundament of the structure I proposed >>>>>>>>>>>>>>>>>> for the spec ( >>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issue= s/30 >>>>>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> /Francis >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>>>>>> *From:* Fabien Imbault >>>>>>>>>>>>>>>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>>>>>>>>>>>>>>>>> *To:* Francis Pouatcha >>>>>>>>>>>>>>>>>> *Cc:* txauth@ietf.org ; Dick Hardt < >>>>>>>>>>>>>>>>>> dick.hardt@gmail.com>; Tom Jones < >>>>>>>>>>>>>>>>>> thomasclinganjones@gmail.com>; Denis ; >>>>>>>>>>>>>>>>>> Justin Richer >>>>>>>>>>>>>>>>>> *Subject:* Re: [GNAP] Review of >>>>>>>>>>>>>>>>>> draft-ietf-gnap-core-protocol-00 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Would make sense, but not so easy as we rely heavily on >>>>>>>>>>>>>>>>>> HTTP. Hence the discussion about deep links and so on. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> An alternative might be provided by wasm/wasi (running a >>>>>>>>>>>>>>>>>> local sandbox on your phone, for your own AS), but it's = really early stage. >>>>>>>>>>>>>>>>>> This also poses another question that Denis has put forw= ard, i.e. how do we >>>>>>>>>>>>>>>>>> handle the multiple AS scenario (likely to occur then). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha < >>>>>>>>>>>>>>>>>> fpo@adorsys.de> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We are drifting away from the original problem space. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - My original mention was about the "POST" request, >>>>>>>>>>>>>>>>>> that subsumes that the "AS" is a "Server". Designing = a new protocol, we >>>>>>>>>>>>>>>>>> cannot afford this limitation. >>>>>>>>>>>>>>>>>> - I just mentioned SIOP to show a known and closed >>>>>>>>>>>>>>>>>> example? Let us not focus on the device local discove= ry scheme (like >>>>>>>>>>>>>>>>>> openid:) for now. >>>>>>>>>>>>>>>>>> - As capability of holding private keys on user >>>>>>>>>>>>>>>>>> device evolves, server-based issuing of token will be= fading out giving way >>>>>>>>>>>>>>>>>> to device local generation of token. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> While designing GNAP, let us assume the AS-Role can be >>>>>>>>>>>>>>>>>> exercised on a user device and design the protocol to ho= nor that. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>> /Francis >>>>>>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>>>>>> *From:* TXAuth on behalf of >>>>>>>>>>>>>>>>>> Dick Hardt >>>>>>>>>>>>>>>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>>>>>>>>>>>>>>>>> *To:* Tom Jones >>>>>>>>>>>>>>>>>> *Cc:* Fabien Imbault ; Denis < >>>>>>>>>>>>>>>>>> denis.ietf@free.fr>; GNAP Mailing List = ; >>>>>>>>>>>>>>>>>> Justin Richer >>>>>>>>>>>>>>>>>> *Subject:* Re: [GNAP] Review of >>>>>>>>>>>>>>>>>> draft-ietf-gnap-core-protocol-00 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Got it. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So web apps invoke a openid: deep link and hope there is >>>>>>>>>>>>>>>>>> an app to handle the openid: scheme? ... and that it is = the user's wallet >>>>>>>>>>>>>>>>>> rather than some malware that has registered openid: on = the mobile device? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> A native app can attempt to open a deep link associated >>>>>>>>>>>>>>>>>> with an app, and will fail if the app is not there. If t= he app is there, it >>>>>>>>>>>>>>>>>> will be opened, so this can't be used to silently test i= f an app is >>>>>>>>>>>>>>>>>> present, but it does allow a native app to provide an al= ternative >>>>>>>>>>>>>>>>>> experience if an app is not present. I don't think this = works with custom >>>>>>>>>>>>>>>>>> schemes ... and I don't know how it could work from a we= b app on the phone >>>>>>>>>>>>>>>>>> with the current Safari APIs. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Apple warns against using custom schemes [1] ... but >>>>>>>>>>>>>>>>>> perhaps they can be convinced to make openid: a managed = scheme similar to >>>>>>>>>>>>>>>>>> mailto:, tel:, sms:, facetime: ? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>>> https://developer.apple.com/documentation/xcode/allowing= _apps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for= _your_app >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones < >>>>>>>>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> You are - that is not standard which is opeind:// >>>>>>>>>>>>>>>>>> This is the one step that still needs to be optimized fo= r >>>>>>>>>>>>>>>>>> SIOP to have good UX. >>>>>>>>>>>>>>>>>> Peace ..tom >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt < >>>>>>>>>>>>>>>>>> dick.hardt@gmail.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Tom >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I watched your video (I watched at 2X speed) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Looks like the employment website app that is using >>>>>>>>>>>>>>>>>> localhost:8765 to communicate with the wallet. Am I corr= ect? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> /Dick >>>>>>>>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones < >>>>>>>>>>>>>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Well, here's a demo. Note that in this case the AS is no= t >>>>>>>>>>>>>>>>>> online all of the time, so it is really implicit flow an= d the OIDC id-token >>>>>>>>>>>>>>>>>> comes from the siop device directly. >>>>>>>>>>>>>>>>>> (whether this is front-channel or back channel is no >>>>>>>>>>>>>>>>>> longer an interesting question.) >>>>>>>>>>>>>>>>>> Now if an always-on AS is required, that is possible, bu= t >>>>>>>>>>>>>>>>>> probably beyond the scope of this effort and would requi= re something like >>>>>>>>>>>>>>>>>> an agent-in-the-sky (with diamonds). >>>>>>>>>>>>>>>>>> here is the link to the 9 min video https://youtu.be >>>>>>>>>>>>>>>>>> /Tq4hw7X5SW0 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Peace ..tom >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer < >>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Ultimately, in most situations like these in the real >>>>>>>>>>>>>>>>>> world, the hurdle isn=E2=80=99t technical compatibility = so much as it is trust >>>>>>>>>>>>>>>>>> compatibility. The RP (client) needs to have some incent= ive to trust the >>>>>>>>>>>>>>>>>> assertions and identity information that=E2=80=99s comin= g from the AS. The same is >>>>>>>>>>>>>>>>>> true for an RS trusting tokens from the AS. The hard que= stion is less =E2=80=9Chow=E2=80=9D >>>>>>>>>>>>>>>>>> to do that (which SSI answers), but more =E2=80=9Cwhy=E2= =80=9D to do that (which SSI >>>>>>>>>>>>>>>>>> doesn=E2=80=99t answer very well, because it=E2=80=99s a= hard question). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Still: it=E2=80=99s definitely a question about how to s= upport >>>>>>>>>>>>>>>>>> this =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99= ve got the start of it more than >>>>>>>>>>>>>>>>>> OAuth2/OIDC have by allowing the bootstrap of the proces= s from a starting >>>>>>>>>>>>>>>>>> call: the interaction and continuation URIs handed back = by the AS don=E2=80=99t >>>>>>>>>>>>>>>>>> need to be the same URIs that the client starts with, so= just like SIOP the >>>>>>>>>>>>>>>>>> process can start in HTTP and potentially move to other = communication >>>>>>>>>>>>>>>>>> channels. A major difference is that we aren=E2=80=99t d= ependent on the assumption >>>>>>>>>>>>>>>>>> that the user will always be in a browser at some stage,= and so the whole >>>>>>>>>>>>>>>>>> raft of front-channel messages that SIOP relies on doesn= =E2=80=99t fly. That said, >>>>>>>>>>>>>>>>>> we=E2=80=99ve got an opportunity to more explicitly open= up alternative >>>>>>>>>>>>>>>>>> communication channels here, and that=E2=80=99s somethin= g I=E2=80=99d like to see >>>>>>>>>>>>>>>>>> engineered, even if it=E2=80=99s an extension. I=E2=80= =99d love to see a concrete proposal >>>>>>>>>>>>>>>>>> as to how that would work over specific protocols, start= ing with what we=E2=80=99ve >>>>>>>>>>>>>>>>>> got today. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault < >>>>>>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Denis, hi Francis, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> At some point integration with SSI (on the authenticatio= n >>>>>>>>>>>>>>>>>> side) will probably occur, including amongst other possi= bilities SIOP >>>>>>>>>>>>>>>>>> (since they work with OpenID a part of the work will pro= bably be made >>>>>>>>>>>>>>>>>> easier). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> That being said, Denis is right. It's not an AS. >>>>>>>>>>>>>>>>>> Technically it's entirely possible to rely on a decentra= lized wallet (for >>>>>>>>>>>>>>>>>> instance on your phone) and a centralized AS. I know of = a few studies on >>>>>>>>>>>>>>>>>> how to decentralize the AS itself (for instance >>>>>>>>>>>>>>>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentr= alized-02 >>>>>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>>>>> Maybe it exists, but I'm still looking for real scenario= s >>>>>>>>>>>>>>>>>> (or even architectures) where an AS is deployed directly= on a phone, and >>>>>>>>>>>>>>>>>> under the sole authority of the RO, while being compatib= le with the rest of >>>>>>>>>>>>>>>>>> the world. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>> Fabien >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hello Francis, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> See two comments in line. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> B) Current Document >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Roles description shall not hold any assumption on the >>>>>>>>>>>>>>>>>> physical structure of the party fulfilling the roles. >>>>>>>>>>>>>>>>>> [FI] not sure what you mean >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> [FP] for example, we assume the AS is a server! In most >>>>>>>>>>>>>>>>>> SSI based use cases, the AS will be running on the user = device. See SIOP ( >>>>>>>>>>>>>>>>>> https://identity.foundation/did-siop/). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I browsed through the two drafts, i.e. : >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - Decentralized Identifiers (DIDs) v1.0 Core >>>>>>>>>>>>>>>>>> architecture, data model, and representations W3C Wor= king Draft 08 November >>>>>>>>>>>>>>>>>> 2020 >>>>>>>>>>>>>>>>>> - Self-Issued OpenID Connect Provider DID Profile >>>>>>>>>>>>>>>>>> v0.1. DIF Working Group Draft >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> At no place within these two documents, it is possible t= o >>>>>>>>>>>>>>>>>> imagine that "the AS will be running on the user device"= . >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> From section 3 of the DIF Working Group Draft: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> "Unlike the OIDC Authorization Code Flow as per >>>>>>>>>>>>>>>>>> [OIDC.Core], the SIOP will not return an access token to= the RP". >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> An Identity Wallet is not an AS. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Roles: >>>>>>>>>>>>>>>>>> -> grant endpoint of the AS: Why is this a post request? >>>>>>>>>>>>>>>>>> This eliminates the chance of having user device hosted = AS (no server). >>>>>>>>>>>>>>>>>> [FI] what would you propose instead? >>>>>>>>>>>>>>>>>> Would also be interested to understand better the >>>>>>>>>>>>>>>>>> deployment model when there is no server. That's somethi= ng that was >>>>>>>>>>>>>>>>>> discussed several times but I'm still missing the underl= ying architecture >>>>>>>>>>>>>>>>>> and use case. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> [FP] See above (SIOP). There will be a lot of identity >>>>>>>>>>>>>>>>>> wallets operated on end user device. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> See the above comment. Please, do not confuse an Identit= y >>>>>>>>>>>>>>>>>> Wallet with an Authentication Server (AS). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Denis >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it >>>>>>>>>>>>>>>>>> authorize the request or the access to a resource? >>>>>>>>>>>>>>>>>> [FI] yes, we should make the wording clearer >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Missing Section Interactions: >>>>>>>>>>>>>>>>>> --> This section shall introduce the notion of >>>>>>>>>>>>>>>>>> interaction before we start listing interaction types. >>>>>>>>>>>>>>>>>> [FI] yes >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Interaction Types: >>>>>>>>>>>>>>>>>> --> I prefer a classification with Redirect, Decoupled >>>>>>>>>>>>>>>>>> and Embedded is. In the draft, we have one redirect and = 2 decouple >>>>>>>>>>>>>>>>>> interactions and nothing else. >>>>>>>>>>>>>>>>>> [FI] this should be handled as a specific discussion >>>>>>>>>>>>>>>>>> item. As a reminder, how would you define embedded? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In practice there's at least these modes: >>>>>>>>>>>>>>>>>> - redirect and redirect back >>>>>>>>>>>>>>>>>> - redirect to different browser or device >>>>>>>>>>>>>>>>>> - user code >>>>>>>>>>>>>>>>>> - CIBA >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> [FP] This classification is limited. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - Redirect: same device, same or different user >>>>>>>>>>>>>>>>>> agents (browser, mobile app, desktop app, ...) >>>>>>>>>>>>>>>>>> - Decoupled: different devices >>>>>>>>>>>>>>>>>> - Embedded : RC carries RO authorization to AS >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Resource Access Request vs. Resource Request >>>>>>>>>>>>>>>>>> --> Both are mixed up. No clarification of the context o= f >>>>>>>>>>>>>>>>>> each section. >>>>>>>>>>>>>>>>>> [FI] could you clarify what you'd expect. Btw on this >>>>>>>>>>>>>>>>>> topic, there's a more general discussion on whether we s= hould make a >>>>>>>>>>>>>>>>>> distinction or not. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> [FP]: Here: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - Resource Access Request: Requesting Access to a >>>>>>>>>>>>>>>>>> resource. Response is an access token (or any type of= grant) >>>>>>>>>>>>>>>>>> - Resource Request: Request the resource. Response is >>>>>>>>>>>>>>>>>> the resource (or a corresponding execution) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Token Content Negotiation >>>>>>>>>>>>>>>>>> --> Not expressed as such. This is central to GNAP and >>>>>>>>>>>>>>>>>> not represented enough in the document. >>>>>>>>>>>>>>>>>> [FI] right. This should be a specific discussion item. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Requesting "User" Information >>>>>>>>>>>>>>>>>> we identify two types of users: RQ and RO. It will be >>>>>>>>>>>>>>>>>> better not to refer to a user in this draft, but either = to a RQ or an RO. >>>>>>>>>>>>>>>>>> [FI] yes that would avoid potential misunderstandings. >>>>>>>>>>>>>>>>>> Although in the end, people will translate RQ into user = or end-user most of >>>>>>>>>>>>>>>>>> the time. Cf in definition, currently we have Requesting >>>>>>>>>>>>>>>>>> Party (RQ, aka "user") >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Interaction Again >>>>>>>>>>>>>>>>>> -> For each interaction type, we will have to describe >>>>>>>>>>>>>>>>>> the protocol flow and the nature and behavior of involve= d Roles (Parties), >>>>>>>>>>>>>>>>>> Elements, Requests. >>>>>>>>>>>>>>>>>> [FI] yes >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> [FP] Will these and into tickets? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Best regards. >>>>>>>>>>>>>>>>>> /Francis >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>> TXAuth mailing list >>>>>>>>>> TXAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>> >>>>>>>>> >>>>>>>> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --00000000000003f5ef05ba9cdaef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adrian,

W= e would be glad to get your expertise on that. Not sure DIDComm is essentia= l yet, so far I see it personally as something to look into, especially for= use cases when we want to reach out to a RO. I agree with the potential is= sues.=C2=A0

I have a few= ideas on how to implement privacy, but it's quite involved in terms of= crypto (again using Ristretto groups :-)).

Of course there will be a question of priority in the f= eatures we plan to implement. I guess we should aim for a first publication= without the parts which are blurry, and take the time to prototype the res= t.=C2=A0

Cheers
Fabien=C2=A0

Le ven. 5 f=C3=A9vr. 2021 =C3=A0 21:19, Ad= rian Gropper <agropper@healthu= rl.com> a =C3=A9crit=C2=A0:
=
There are privacy implications as well as the cost of proc= essing spam. A service endpoint associated with a DID can be presumed to be= a public broadcast. Any party can attempt to send a message or an authoriz= ation request to that service endpoint. The operator of that service, typic= ally the DID controller, will bear the cost and risk of processing the mess= age. They may request a bond be posted by the party responding to the "= ;broadcast" in order to mitigate spam and phishing. They may also requ= ire that the party seeking to communicate offer credentials, which poses a = privacy risk to that party in the form of phishing "broadcasts" v= ia DIDs and lures that lead to DIDs.=C2=A0

In my role as= invited expert on privacy to some W3C WGs and, to some extent, DIF WGs, I = have not managed to understand the privacy engineering and implications in = DIDcomm. I will try harder if DIDcomm has an essential role with GNAP and I= can understand it in the self-sovereign or fiduciary authorization server = context. Does it?

Adrian

On Fri, Feb 5, 2021 = at 1:08 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:=
Probably (and to be honest even= for industrial users I find it complex), but alternatives are not ready fo= r prime time either.=C2=A0
Maybe some day=C2=A0DIDComm could be useful = as a basic block, what we suggest is to first use that as a potential inter= action (and there's already a lot of questions that arise just from tha= t).=C2=A0

Fabien

On Fri, Feb 5, 2021 at 6:55 = PM Tom Jones <thomasclinganjones@gmail.com> wrote:
<= /div>
No, you didn't misunderstand me= . It's just that the ux for that is not acceptable to retail users. As = long as gnap sticks to industrial users you should do fine.

thx= ..Tom (mobile)

On Fri, Feb 5, 2021, 7:56 AM Fabien Imbault <= fabien.imbault@gmail.com> wrote:
Targeting existing browsers and types of ap= plications (web, pwa, mobile, etc.) seems like a reasonable option for an i= ndustrial standard. Improving security, privacy, ease of use and interopera= bility (including decentralized identity as well) should be good enough obj= ectives.=C2=A0
Plus from our previous discussions, I was under th= e impression you were fine with the approach of deploying the AS on the pho= ne as a loopback, for mobile apps. Did I miss something?

Cheers,
Fabien

Le ven.= 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones <thomasc= linganjones@gmail.com> a =C3=A9crit=C2=A0:
If you mean can GNAP work on old fashioned apps runn= ing with existing browsers and existing identity providers, then yes, i gue= ss you are ok.

If you want to work on apps where t= he user is in control of authn and authz, then no, GNAP cannot work. It is = not alone in that OIDC wont work there either.

Be the change you want to see in the world <= /span>..tom


On Fri, Feb 5, 2021 at 3:19 AM= Fabien Imbault <fabien.imbault@gmail.com> wrote:




Cheers
Fabien=C2=A0

<= div class=3D"gmail_quote" dir=3D"auto">
Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit=C2=A0:
discovery is the prime problem.=C2=A0 What cau= ses the wallet/AS to wake up and pay attention. How does the RP know what t= o ask for without violating user privacy rights?

CHAPI w= ould be ok i guess, but that requires cred man to be fixed. Not sure if it = fixes discovery or privacy even then.

Be the change you want to see in the world ..= tom


On Thu, Feb 4, 2021 at 12:45 PM = Justin Richer <jricher@mit.edu> wrote:
Tom, what additional functionality do you see tha= t a browser would need to support in order for GNAP to be adopted? For the = elements of the core protocol today, nothing is needed to change within the= browsers =E2=80=94 everything is built on existing functions. GNAP uses br= owsers as a tool, and I would argue depends on them even less so than OAuth= 2 does. Extensions could use browser functionality, like using CHAPI to pa= ss interaction elements, but the core protocol functions on vanilla browser= s today.

=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 3:20 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

i assumed that the wallet (aka AS) needed to be a nativ= e app, not a PWA (which can come from a traditional web server).
There = are folks, lke Kim C, who are working on a PWA, but i agree the blocks ther= e seem to be large.
THe blocks on a native app are simple, easy t= o describe, and easy to ask the browser guys to fix. Not sure if they care = tho.
I have trouble seeing a path to GNAP adoption for retail cus= tomers w/o some browser support.
That's why i am mostly=C2=A0= silent here.

Be the change you want= to see in the world ..tom

On Thu, = Feb 4, 2021 at 11:43 AM Fabien Imbault <fa= bien.imbault@gmail.com> wrote:
Fair enough. But loopback limits a lot what you can do... Just for d= ebug it's a pain.=C2=A0
But as soon as you try more, i= t's a bit crazy. Fun to test ipv6 (luckily supported by my ISP) and ddn= s. But it feels really hacky.=C2=A0
Also deployment = is a pain, compared to a traditional webserver.=C2=A0

Le jeu. 4 f=C3= =A9vr. 2021 =C3=A0 20:20, Tom Jones <thomasclinganjones@gmail.com= > a =C3=A9crit=C2=A0:
doesn= 't work very well on windows uwp. works fine on smartphones
Be the change you want to see in the world ..= tom


<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 4, 2021 at 11:18 AM Justin= Richer <jricher@mit.edu> wrote:
= OK, thanks =E2=80=94 in that case, there are no changes at all to GNAP, whi= ch is already HTTP driven. The harder parts tend to be where you can=E2=80= =99t (or don=E2=80=99t want to) use something like that.

=C2=A0=E2=80=94 Justin

On Feb 4= , 2021, at 2:16 PM, Tom Jones <thomasclinganjones@gmail.co= m> wrote:

yes, loopback

Be the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:01 AM = Justin Richer <jricher@mit.edu> wrote:
Tom, can you expand on how exactly the back-channel =C2=A0communicati= on works between on-device components? Do you use HTTP locally?

Thanks,
=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 1:03 PM, Tom Jones <th= omasclinganjones@gmail.com> wrote:

Ju= stin's analysis of use of the front channel is misleading.
It could= equally be argued that what i have done is installed an AS on the phone an= d the communications with it & the PR is back channel.
Basica= lly the point is that the old OIDC paradigms are no longer valid.
Be the change you want to see in the world ..to= m


On Thu, Feb 4, 2021 at 7:47 AM Fabien Im= bault <fabien.imbault@gmail.com> wrote:
Yes, issue (#168)=C2=A0message based interactio= n / DIDComm is a tentative alternative mecanism for the interaction part. N= ot sure how that would work in details=C2=A0though, prototyping will probab= ly help here.
Token delivery=C2=A0through continuation seems fine to me= . The client will probably have to wait for the next polling before it rece= ives a token issued as the result of an asynchronous interaction, but that&= #39;s not a big issue.

But the AS on the phone see= ms like a harder nut to crack, at least at first sight. I think that would = be awesome, but it gives me headaches, so I think I'll work on easier s= tuff right now ;-)

Fabien=C2=A0=C2=A0

On = Thu, Feb 4, 2021 at 4:30 PM Justin Richer <jricher@mit.edu> wrot= e:
One of the biggest drawbacks of the curre= nt app-centric approaches in OIDC (self-issued OP, or SIOP) is that they de= pend on using the front channel and browser redirects to pass everything, w= hich is something that GNAP is deliberately getting away from by starting i= n the back channel.

That said, once a request is kicked = off in GNAP, the interaction and fulfillment can happen through any number = of means. Part of the work that=E2=80=99s being done with the =E2=80=9Cinte= raction=E2=80=9D section is going to help facilitate this, and I think that= there are some other potential branches here.

Tok= en delivery is where things get extra weird though =E2=80=94 we are explici= tly not delivering tokens in the front channel in the core of GNAP, we=E2= =80=99re using the response from the continuation API. One idea (that isn= =E2=80=99t particularly well thought out and hasn=E2=80=99t been implemente= d at all) is to have an extension declare an alternative response from the = =E2=80=9Ccontinue=E2=80=9D section that=E2=80=99s defined today, which poin= ts to the GNPA continuation API. If an extension defines some alternative w= ay to deliver tokens, that could live alongside a continuation API and the = client could indicate support for it in its initial request.

=
In any event, alternative interaction and delivery methods are i= mportant, and even if we aren=E2=80=99t going to support every last one of = them directly, the protocol design should at least be aware of them.
<= div>
=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 8:35 AM, Fabien Imbault <fabien.i= mbault@gmail.com> wrote:

Hi Tom,=C2= =A0

Sure, any experience on that would be greatly apprec= iated, we're calling for help here (the point being that I suspect what= they're doing is not trivial).

Fabien

On= Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones= @gmail.com> wrote:
I= 9;ve had such an app working for over a year. There are issues which are be= ing addressed by the browser Interaction team of oidc.

thx ..To= m (mobile)

On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault <f= abien.imbault@gmail.com> wrote:
Hi Francis,=C2=A0

I've tried a few things w= ith regards to using the AS on a phone, but it's really quite=C2=A0comp= lex.=C2=A0

Making that run on a phone comes with q= uite a bit of trouble. The most difficult part if that we'd need to use= a secure element, but just installing and hosting a http server securely i= s not a standard setup at all. I suggest interested people step in to work = on this, as we already have a lot of work for the (more usual) server case = and already handle a privacy preserving scheme.=C2=A0

<= div>Please let us know what you think.

Cheers,
Fabien=C2=A0

On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault <= ;fabien.imbault@gmail.com> wrote:
Hi Francis,

=
I've thought a bit more to what you said. I think I&#= 39;ll give it a try as a separate experiment (in code, not in theory). Not = that I would expect it to be included in GNAP, but I kind of like the idea = :-)

The direct impact fo= r GNAP would be to think about multiple ASs.=C2=A0
<= br>
Will let you know.=C2=A0
=
Fabien=C2=A0


Le mer. 18 nov. 2020 =C3=A0 13:= 06, Francis Pouatcha <fpo@adorsys.de> a =C3=A9crit=C2= =A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"m_-9198896947569259166gmail-m_2454565993824225076gmail-m_48154607178834= 67013m_4588137701409402545m_3740723253088693496m_-99671316316621892gmail-m_= 4891442230495737020m_-8218552788289986907m_-8518815978092546954m_3550419800= 836567560m_-8251187544229342067m_6649396458130137896m_3308803089207789488m_= -435436554859614529m_2888166142485750597gmail-m_7901394266816005280gmail-m_= -6718184999452512077m_-3004232231493229381m_-8862550958674531306m_455265398= 4562635461m_387929924441527190m_6662104191003806385gmail-m_-542839070341023= 388gmail-m_-6176056956474019294gmail-m_-3037161202240578685gmail-m_-7520389= 457378808664gmail-m_-3342024782330569254m_8014700032835912204gmail-m_142651= 873244800559m_8348797445460806175LPlnk338391" rel=3D"noreferrer noreferrer = noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferre= r noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer norefer= rer noreferrer" target=3D"_blank">https://github.com/ietf-wg-gnap/gnap-core= -protocol/issues/30).

/Francis

From: Fabien Imb= ault <fabien.imbault@gmail.com> Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>= ;
Cc: txauth@ietf.org <txauth@ietf.org>; Dick Hardt <d= ick.hardt@gmail.com>; Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer <jri= cher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@adorsys.de> wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-bounce= s@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganj= ones@gmail.com>
Cc: Fabien Imbault <fabien.imbaul= t@gmail.com>; Denis <denis.ietf@free.fr= >; GNAP Mailing List <txauth@ietf.org&= gt;; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?

3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0h= ttps://youtu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oaut= h-decentralized-02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://id= entity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= [FP]: Her= e:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txa= uth

--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--00000000000003f5ef05ba9cdaef-- From nobody Sat Feb 6 23:46:11 2021 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 6741B3AFA41 for ; Sat, 6 Feb 2021 23:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=mnot.net header.b=F6CPfK7I; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EWiWz+7T 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 CHhqSTGzBFsF for ; Sat, 6 Feb 2021 23:46:06 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8473AFA3F for ; Sat, 6 Feb 2021 23:46:06 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 556F8B89 for ; Sun, 7 Feb 2021 02:36:44 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 07 Feb 2021 02:36:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=zI05FrqjDu846aBbxxhonXMeB9Rc6PMQGE2i6r3Najc=; b=F6CPfK7I l2kI7zy6k8QQQVhHKlSzig8bGlkIz240HMPd6s0ciFQOUCGgoZv56PgAm2MY4zJ2 SUcd0KLZzkEXSEzSEXdOeF7iHh2Ao/5OU1Oi6axDHhuaGpDtIEZ359PWcb9gOxnS S8A2map25oXF7ymjgGRZRcdP/4WaOow8BtddSdjyzvTQJEzBDACYP3cGp9BeJZzS 1e0kIBa3BKbF+jY8uJrQ5SCxnMtW0tB8Q09/7stkhfz0fkby6aNR8Pt0fCPAiNHu zDxNJkH+HLwGN4vmxkoZouCL+zkMc6PGNC6t6w8nckZq7j70XofJqh9ywLH8J7hP 2hF5QXnXqwkwrQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=zI05FrqjDu846aBbxxhonXMeB9Rc6 PMQGE2i6r3Najc=; b=EWiWz+7TL7iVqD1WSuOjlJBahrhqia1PQxEfOq2p3Fs4a mQQrAPMbdMspaY8OxE+4a8RF1Es+m08yDL57UXuHALpU88NCCl18oIKKRLs75z9e 3TvLdCRrHjaw/No80Vy3ldP2RDODM3+rMSKgLlvlFeq5OksTAp45d54kcqwNUnmE 8CjTGtOldIBVEmwPnMM4yYyClN130pkhph/VSOawnnl1smmSc4Nhesrgs/w7o0qB uam+Ktm/qaGhOnfphrvfFeUMhCCJUIbSEAUVmlGMWVi0xj59rb7i1f1PTA4AgXTl xoD8cepszujpfT8KI1DuZku9Bh6RURRIKxySf2CCg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrhedtgddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtthgvrh hnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudeiteen ucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrieehrddvtdefrddvfe ehnecuvehluhhsthgvrhfuihiivgepheenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az59-276.internal.cloudapp.net (unknown [40.65.203.235]) by mail.messagingengine.com (Postfix) with ESMTPA id C7A801080057 for ; Sun, 7 Feb 2021 02:36:43 -0500 (EST) Content-Type: multipart/alternative; boundary="===============4341076237505488757==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210207073643.C7A801080057@mailuser.nyi.internal> Date: Sun, 7 Feb 2021 02:36:43 -0500 (EST) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 07:46:09 -0000 --===============4341076237505488757== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-gnap/core-protocol (+4/-1/=F0=9F=92=AC13) 4 issues created: - token based delegation (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/169=20 - message based interaction / DIDComm (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/168=20 - Define which "resources" fields are optional (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/167=20 - Create JSON Schema (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/166=20 7 issues received 13 new comments: - #169 token based delegation (4 by agropper, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/169=20 - #168 message based interaction / DIDComm (1 by agropper) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/168=20 - #167 Define which "resources" fields are optional (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/167=20 - #166 Create JSON Schema (2 by fimbault, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/166=20 - #122 Group interaction mode flags (3 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/122=20 - #89 Multi-step interaction methods (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/89=20 - #15 Token Binding (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/15=20 1 issues closed: - Unique callback URIs https://github.com/ietf-wg-gnap/gnap-core-protocol= /issues/55 [Pending Close]=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #4 added starter JSON schemas in appendix (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/4=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============4341076237505488757== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (GNAP Weekly GitHub Activity Summary)

Sunday February 07, 2021

Events without label "editorial"

Issues

ietf-wg-gnap/core-protocol (+4/-1/=F0=9F=92=AC13)

4 issues created:

7 issues received 13 new comments:

1 issues closed:

Pull requests

ietf-wg-gnap/core-protocol (+0/-0/=F0=9F=92=AC1)

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============4341076237505488757==-- From nobody Sun Feb 7 14:51:32 2021 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 8A57E3A1411 for ; Sun, 7 Feb 2021 14:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=adorsys.de 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 LmapSqQJY3wV for ; Sun, 7 Feb 2021 14:51:25 -0800 (PST) Received: from DEU01-BE0-obe.outbound.protection.outlook.com (mail-be0deu01on2104.outbound.protection.outlook.com [40.107.127.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F453A1410 for ; Sun, 7 Feb 2021 14:51:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PH6OQNbaDDxZxneynvPD+rLd1uWveN//M77B/q+XUzUGRjug2Fu4uH2V0WPmUSOVYuwv1b+gEZ9LZvZoSYlXDtt8wDjEOVQoY5YU8alS6Xq6L0OwUBkyqXEebmxVW2GyVUAKYijJZxokxUI4vvne4TIQy7Qdr6C5N2rzqZ1JGr4UXu8kjzOAW7u47gjkt0eQcb2B+Zd5v3/jKsrHoOd7orw72wBxCGQM567Dc4W3Lu57oJ/oRRZ1dXE3lRnC4CecIkTFWU+0+wQjnGHc46yXc3TpfHrU9PDZ8it09uZlejcgK0UTPmc7EGmmDIUlorZUUdf4XugJrKpjMP6yEKlofA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LppufL+Uovr8uJ54cituTPFhtkz9bXwHttCjkmuJ0Go=; b=QwKPaJikiC9YneGhZ6z0Y5BRXhAX5sA+owrwNztnvi/Gnn4P67rge37M0QnpnEU0wh7y9w+WSFZII26yWXPGQH/I1mq3jpchB3V9HMxCe/9BSbcoUnpSqL8tMdsqyMKC5wMgp/LJra8StCk1iKwckF8aIASrP+hBGnSoz9u6PYN483YSFp8Ix1Ffkl+Puo3RYTV5k9CtVxlmA0oo9Y05wUD7vqngNSglFwSE8xbiEZQ1oV820oXY9iWeC3yk/AxlKrLjbcPZTsXh0kiKSiiDTNYb0GOsEVm+jA/k24syg1Q34guJq63tBnPDufpyRb23V22NO9fQm6oZyWlPNYxKqA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=adorsys.de; dmarc=pass action=none header.from=adorsys.de; dkim=pass header.d=adorsys.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LppufL+Uovr8uJ54cituTPFhtkz9bXwHttCjkmuJ0Go=; b=vJTBezrQPkV3wcksIgOO8C5+9lPHYo8UbJOPx/X3oKOtfdzoY+Umc09dJOdjoCyiO0SkaY/5cEBcszrjcTxUB8QAxUB5+yPQbbFl6w7jVhrfgNMtZi5tv5ab1C4Gbo/ZnSnMWA5ZzNXeTFzPQAwOrln8q9uYaKkdH+u/uPO/0sJHSMdWRpSozZJ+/mdO25gwfR9Id3PeS0CvJWRd5bn88A0qzwA0eP/8gqHxllPlVdwot9kgCTGhR1QR6ocF93xN/NEiQ1r8GYU18lQPSN3AgZ1TFhgz42yoZomkJVEsdUNIFEoE5m/juZW4L6CYCNdaNyuN47zQhx0mcfDJKpFuVw== Received: from (2603:10a6:d10:11::11) by FR2P281MB0219.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.10; Sun, 7 Feb 2021 22:51:20 +0000 Received: from FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM ([fe80::858a:948b:efd1:953e]) by FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM ([fe80::858a:948b:efd1:953e%4]) with mapi id 15.20.3846.025; Sun, 7 Feb 2021 22:51:20 +0000 From: Francis Pouatcha To: Fabien Imbault , Adrian Gropper CC: Tom Jones , txauth gnap , Justin Richer Thread-Topic: [GNAP] Review of draft-ietf-gnap-core-protocol-00 Thread-Index: AQHWsiy3H8is1hHc2keFJtXpCHRvoKnGFMOAgATzTCaAAZWSAIAABTGAgAAETgCAAAeTAIAAA4oAgAACAwCAAAZDgIABFPt3gAAJ5ACAAAKPuYAI+9sAgHGRGICAACQjgIAAA7SAgAAgOQCAAATOAIAAJgQAgAAQNwCAAASqH4AAAEyAgAAGvACAAApFgIAABumAgAAHAYCAAO1PgIAARvqAgAAGU4CAACFUAIAAA2CAgAAk9YCAAAYlgIADPi+m Date: Sun, 7 Feb 2021 22:51:20 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=adorsys.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2603:9000:780a:f3b8:1849:41aa:9cbf:6f0d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7f49474d-a01e-4e68-a38d-08d8cbbae324 x-ms-traffictypediagnostic: FR2P281MB0219: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IYCjjbslct3ZvUKR46Y8ULQ+DFAyTSMVGTCMaMkjzASxp1OysiWQ487sT9iIIz6J4taRWR2TrEmzVsp2n5gOak44HAQXIJAsc6vWTq0Ou9o1+2UkURLG/raxPMAaw9+r2hFUmpDLRLYlqoeIuInPqSK5K1TMw48Kx0hNiTHN+txLSZd0O2ZOYzU1+FwjQXJ10hM0E5rYj5cmKjwSq/LzfgznOjklckAJQ0YYI8KjN53yxJ+SKbcXfShhCN9Rw0UmWbGBLpsvWstoSOFHxXTfXd75WgVFThcGNtrayC3fPCvR2WT5oSxRdCVemSXeWa+Q87SlA23UdX+sGVjinmSlXl0Z6ieHUWb58oAU1Cd1R4aW7W6fzq8xTGlSrY0H+fMfquO2vMkIRv8//rM639adFh2IynVhHgocpF/8R6gnUqNspJX0LCOIPLFozy7ctv1dFt7LPJwY5P6frPK7E0i1u0lr3zj+DHIQRkXpr7FC7nmyLNwux26pCxKzM2OuLKK4iAOBNU+jSt0bPgdN7I9AN5eDVUyAgbDWiCUKCSsnNPEpYUdxeVlY+8sKMm0HuAyfVwumSLwaNQZ/Se+szX9igmku0bfYyPjbih9bjN45mnqaVqyq000iNAQrJAQdY44N32M6VtBZ2Rq6r9Psj5AfmVBTzGkaMN1GT6ccQgNM/IcmvlkT2lONhpns/vowT9qt x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(136003)(396003)(376002)(39830400003)(33656002)(71200400001)(110136005)(966005)(91956017)(76116006)(186003)(52536014)(9686003)(66556008)(66476007)(5660300002)(30864003)(316002)(54906003)(4326008)(6506007)(66446008)(66946007)(53546011)(64756008)(166002)(8676002)(83380400001)(8936002)(66574015)(478600001)(2906002)(55016002)(7696005)(86362001)(19627405001)(99710200001)(15866825006)(559001)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?ZTRCd1VrVlFQV2pic0VSSGtvdWEzUTQraHhOZUFNV1Z5NkNrQmxvOHVHQ3dM?= =?utf-8?B?MnlNcmN0dnFNLzVma25TbEMxYy9TeFlMbXJxaFZmNHVXbi9XdWpVWFd4S012?= =?utf-8?B?VzRGWmVla3E5T0tRVWFseFl6VUVZbUtFdGlNVUkzbVdlb2xFK1hSR29RVkds?= =?utf-8?B?K0tQTms1OGNhRnpmMXFuc1dTSFZMd0JGRTNGMnAxVjh6cTlXQlduOFlZVXh2?= =?utf-8?B?RjRjblE3UVBMT3hXM0RRY0dMbTcvYjRGOVYzQytFS0xDdWIxeVB5d2FKeTNG?= =?utf-8?B?QnFrSSs5bGIzdkp5N2FNMm9YaTJsTmdDbjhxL2lQYVk4dlVLSmVRakc4cWlU?= =?utf-8?B?N1EyMlM2b3draGJCTmI3Z2tlaGVvUEwyQUl4U0NGcm4wUTQwTng2cDc5Y2VZ?= =?utf-8?B?d0V1MEJGWFdxQWdJdzd5NW5SWmdvVXlFR3R0MS9qR1hWRmdrdmd4MkxqbWtR?= =?utf-8?B?eTlUTXd0eWIrMnVyNjdBNTRaSjl0TzdoYXcybjY1M0RLeGlNTmpyVThyN2dL?= =?utf-8?B?Y2swN1FMWFN6TDhsaTJzQmlITDlDZXYwWi9OenQyYStYYmxtUjZ2RHFkQTgz?= =?utf-8?B?S0hJNVpTVXBleW52bGdqOU1XbXJFMit3T09FRk1sVHhueTBOSW8rd1FIYkdo?= =?utf-8?B?czBHdkV6SFQ2QlhzejdsQnQwZFFnRHVoVEJjTGpMRkMzUVNHQlFMK0FMZldN?= =?utf-8?B?ZnJ6U2lITEpUVDdvdG5Vdmpwakkya0JtUnp0Tm93ZDFmeW9tY3ZxL2tmYWE0?= =?utf-8?B?UzVoOXkvSzh3TE96Yng3NFNDb2VIZW1ITGp6eENvaS9aOWRMVzJrWHhlb0lT?= =?utf-8?B?VGlDdndKemJ4VnVuNjcwRVhLbXg0bVpWUEJaVm50L3h0S1BGVW5STkUzc3NU?= =?utf-8?B?OTZyWUZJSFhRZGdOMy90aGtpLytvdklpRHpYZEEvV1lKTXBEam1aL2p0Umxp?= =?utf-8?B?MlEraW5Sd3NQbktWWXR3Mi8zdXRQNnFHc1V1T2l5YkNMNzczOHFqdlZMTGxF?= =?utf-8?B?Y1FsYXRwbjVPdmN6V1FnYjN1cUlSOGxXYUZQNG95YkxUUUZoWVFVTVdpM3FW?= =?utf-8?B?eVY1dFJDZXJnMWM2bExqN3NMc2hIK05jQW9MWXFhSG85QXZjaXBjdnFpYjlM?= =?utf-8?B?d3BmYnN6Z3l4aCtxYVprcXhVMFlreklrM3k3N0VhYkdNbEhKT3NubHdoYjY5?= =?utf-8?B?WFdqNTlLQmNPcWJXeEIyR1NGRG52Nm1VaVpyZWp1UWVCTlRuUWpIVUJJRmlG?= =?utf-8?B?ODRaaWdvdmdWYUtoSm00OVN3NlVGSGpORFNmZCtxSTFjdWJvQ1AvUnV1d2RU?= =?utf-8?B?ODlLMldMNFNNTXJFZC8xODZNcHBaRGlHS3VzKzZPQnNHamVoek5CNlM3dDEr?= =?utf-8?B?ZWxLcVQrRytIWVJDVTJvUFdEbDdiOTc1M3UzZjYrd29mcndNdks4QUZVRzIz?= =?utf-8?B?VlJLL21mSnpSRGlXa3FWaEpYZlJpL2g0aWVpcHlkZHYyV2tpNDE3NmJIVlpX?= =?utf-8?B?YTkvenJpSWlENjFaeno3ZXlRYlRQK1I0TUcvUTN1YjdVUCszTi9wK2FoemhN?= =?utf-8?B?N3l0d2FtcnJLTXZPdWw3Tk1BZy8yU2pJT2NEYVVYVmFuV1NjVk9PcVFLMEhP?= =?utf-8?Q?OXWchN8BaBOK5mn8hSgPPT9bGmpVibOJpR8viokfkJSo=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FR2P281MB0106C0A62253D04A1070873F8DB09FR2P281MB0106DEUP_" MIME-Version: 1.0 X-OriginatorOrg: adorsys.de X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 7f49474d-a01e-4e68-a38d-08d8cbbae324 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2021 22:51:20.5630 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5e2c5484-e522-479d-91ca-515d6e0ce228 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6SOKGLY9iAnlF9KVt9Nd7mjDa2HHVT5sEJ8OfFBe3uHtNomF2SkIUMlZ8BLeOBJiCN1vrfA6u6GzMIdFKRuo4NygA+kVz7K+HiiVOxpdi7E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB0219 Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 22:51:31 -0000 --_000_FR2P281MB0106C0A62253D04A1070873F8DB09FR2P281MB0106DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gRmFiaWFuLA0KDQpJIGFtIHNvcnJ5IGZvciB0aGUgZGVsYXllZCByZXBseSwgYnV0IHZl cnkgYnVzeSB3b3JraW5nIG9uIHRob3NlIGRlY2VudHJhbGl6ZWQgdXNlIGNhc2VzIHdoZXJlIHRv a2VucyBhIHByb2R1Y2VkIG9uIHRoZSB1c2VyIGRldmljZS4NCg0KDQpMaWtlIHdlIGNhbiBzZWUg aW4gdGhpcyB0aHJlYWQsIGl0IGlzIG5vdCBvYnZpb3VzIHRvIGhhdmUgdGhvc2UgdXNlIGNhc2Vz IGNvbnNpZGVyZWQgaW4gR05BUCAoYXMgdGhlIEdOQVAgY2hhcnRlciBtZW50aW9ucyByZWxpYW5j ZSBvbiBIVFRQIGJhc2VkIEFTKS4NCg0KSWYgdGhlIHJvbGUgb2YgYW4gQVMgaXMgdG8gcHJvZHVj ZSBhbiBhdXRob3JpemF0aW9uLCBhIHVzZXIgZGV2aWNlIGhvc3RlZCBBUyBjYW4gYmUgYnVpbGQs IGJ1dCB0aGUgbmVnb3RpYXRpb24gcHJvY2VzcyB3aWxsIGJlIGRpZmZlcmVudCBmcm9tIHRoZSBv bmUgZGVmaW5lZCBieSBHTkFQLiBNZWFucyBpbnRlcmFjdGlvbiBwcm90b2NvbCB3aWxsIG5lZWQg bW9yZSB0aGFuIGp1c3QgSFRUUC4NCg0KVGhlIGJpZ2dlc3QgY2hhbGxlbmdlIHdlIGFyZSBmYWNp bmcgb24gdXNlciBkZXZpY2UgcHJvZHVjZWQgYXV0aCB0b2tlbnMgaXMgb24gaG93IHRvIHByZXNl cnZlIHRob3NlIGNyeXB0byBrZXlzIGhlbGQgb24gdXNlciBkZXZpY2UgZnJvbSBtYWx3YXJlLCBs b3NzIG9mIGRldmljZS4uLg0KDQpGb3IgdGhlIG1vbWVudCBrZWVwaW5nIGZvY3VzIG9mIEdOQVAg b24gKGh0dHApIHNlcnZlci1iYXNlZCBwcm9kdWN0aW9uIG9mIHRva2VuIGxvb2tzIGxpa2UgYSBn b29kIGRlY2lzaW9uLg0KDQpJIHdpbGwgcmV2aWV3IHRoZSBkcmFmdCBzb21ldGltZSBhcyBzb29u IGFzIHBvc3NpYmxlIGFuZCBwcm92aWRlIG15IGZlZWRiYWNrLg0KDQpCZXN0IHJlZ2FyZHMsDQoN Ci9GcmFuY2lzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBUWEF1 dGggPHR4YXV0aC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRmFiaWVuIEltYmF1bHQg PGZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbT4NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgNSwgMjAy MSAzOjQxIFBNDQpUbzogQWRyaWFuIEdyb3BwZXIgPGFncm9wcGVyQGhlYWx0aHVybC5jb20+DQpD YzogVG9tIEpvbmVzIDx0aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tPjsgdHhhdXRoIGduYXAg PHR4YXV0aEBpZXRmLm9yZz47IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4NClN1Ympl Y3Q6IFJlOiBbR05BUF0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtZ25hcC1jb3JlLXByb3RvY29sLTAw DQoNCkhpIEFkcmlhbiwNCg0KV2Ugd291bGQgYmUgZ2xhZCB0byBnZXQgeW91ciBleHBlcnRpc2Ug b24gdGhhdC4gTm90IHN1cmUgRElEQ29tbSBpcyBlc3NlbnRpYWwgeWV0LCBzbyBmYXIgSSBzZWUg aXQgcGVyc29uYWxseSBhcyBzb21ldGhpbmcgdG8gbG9vayBpbnRvLCBlc3BlY2lhbGx5IGZvciB1 c2UgY2FzZXMgd2hlbiB3ZSB3YW50IHRvIHJlYWNoIG91dCB0byBhIFJPLiBJIGFncmVlIHdpdGgg dGhlIHBvdGVudGlhbCBpc3N1ZXMuDQoNCkkgaGF2ZSBhIGZldyBpZGVhcyBvbiBob3cgdG8gaW1w bGVtZW50IHByaXZhY3ksIGJ1dCBpdCdzIHF1aXRlIGludm9sdmVkIGluIHRlcm1zIG9mIGNyeXB0 byAoYWdhaW4gdXNpbmcgUmlzdHJldHRvIGdyb3VwcyA6LSkpLg0KDQpPZiBjb3Vyc2UgdGhlcmUg d2lsbCBiZSBhIHF1ZXN0aW9uIG9mIHByaW9yaXR5IGluIHRoZSBmZWF0dXJlcyB3ZSBwbGFuIHRv IGltcGxlbWVudC4gSSBndWVzcyB3ZSBzaG91bGQgYWltIGZvciBhIGZpcnN0IHB1YmxpY2F0aW9u IHdpdGhvdXQgdGhlIHBhcnRzIHdoaWNoIGFyZSBibHVycnksIGFuZCB0YWtlIHRoZSB0aW1lIHRv IHByb3RvdHlwZSB0aGUgcmVzdC4NCg0KQ2hlZXJzDQpGYWJpZW4NCg0KTGUgdmVuLiA1IGbDqXZy LiAyMDIxIMOgIDIxOjE5LCBBZHJpYW4gR3JvcHBlciA8YWdyb3BwZXJAaGVhbHRodXJsLmNvbTxt YWlsdG86YWdyb3BwZXJAaGVhbHRodXJsLmNvbT4+IGEgw6ljcml0IDoNClRoZXJlIGFyZSBwcml2 YWN5IGltcGxpY2F0aW9ucyBhcyB3ZWxsIGFzIHRoZSBjb3N0IG9mIHByb2Nlc3Npbmcgc3BhbS4g QSBzZXJ2aWNlIGVuZHBvaW50IGFzc29jaWF0ZWQgd2l0aCBhIERJRCBjYW4gYmUgcHJlc3VtZWQg dG8gYmUgYSBwdWJsaWMgYnJvYWRjYXN0LiBBbnkgcGFydHkgY2FuIGF0dGVtcHQgdG8gc2VuZCBh IG1lc3NhZ2Ugb3IgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0IHRvIHRoYXQgc2VydmljZSBlbmRw b2ludC4gVGhlIG9wZXJhdG9yIG9mIHRoYXQgc2VydmljZSwgdHlwaWNhbGx5IHRoZSBESUQgY29u dHJvbGxlciwgd2lsbCBiZWFyIHRoZSBjb3N0IGFuZCByaXNrIG9mIHByb2Nlc3NpbmcgdGhlIG1l c3NhZ2UuIFRoZXkgbWF5IHJlcXVlc3QgYSBib25kIGJlIHBvc3RlZCBieSB0aGUgcGFydHkgcmVz cG9uZGluZyB0byB0aGUgImJyb2FkY2FzdCIgaW4gb3JkZXIgdG8gbWl0aWdhdGUgc3BhbSBhbmQg cGhpc2hpbmcuIFRoZXkgbWF5IGFsc28gcmVxdWlyZSB0aGF0IHRoZSBwYXJ0eSBzZWVraW5nIHRv IGNvbW11bmljYXRlIG9mZmVyIGNyZWRlbnRpYWxzLCB3aGljaCBwb3NlcyBhIHByaXZhY3kgcmlz ayB0byB0aGF0IHBhcnR5IGluIHRoZSBmb3JtIG9mIHBoaXNoaW5nICJicm9hZGNhc3RzIiB2aWEg RElEcyBhbmQgbHVyZXMgdGhhdCBsZWFkIHRvIERJRHMuDQoNCkluIG15IHJvbGUgYXMgaW52aXRl ZCBleHBlcnQgb24gcHJpdmFjeSB0byBzb21lIFczQyBXR3MgYW5kLCB0byBzb21lIGV4dGVudCwg RElGIFdHcywgSSBoYXZlIG5vdCBtYW5hZ2VkIHRvIHVuZGVyc3RhbmQgdGhlIHByaXZhY3kgZW5n aW5lZXJpbmcgYW5kIGltcGxpY2F0aW9ucyBpbiBESURjb21tLiBJIHdpbGwgdHJ5IGhhcmRlciBp ZiBESURjb21tIGhhcyBhbiBlc3NlbnRpYWwgcm9sZSB3aXRoIEdOQVAgYW5kIEkgY2FuIHVuZGVy c3RhbmQgaXQgaW4gdGhlIHNlbGYtc292ZXJlaWduIG9yIGZpZHVjaWFyeSBhdXRob3JpemF0aW9u IHNlcnZlciBjb250ZXh0LiBEb2VzIGl0Pw0KDQpBZHJpYW4NCg0KT24gRnJpLCBGZWIgNSwgMjAy MSBhdCAxOjA4IFBNIEZhYmllbiBJbWJhdWx0IDxmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb208bWFp bHRvOmZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbT4+IHdyb3RlOg0KUHJvYmFibHkgKGFuZCB0byBi ZSBob25lc3QgZXZlbiBmb3IgaW5kdXN0cmlhbCB1c2VycyBJIGZpbmQgaXQgY29tcGxleCksIGJ1 dCBhbHRlcm5hdGl2ZXMgYXJlIG5vdCByZWFkeSBmb3IgcHJpbWUgdGltZSBlaXRoZXIuDQpNYXli ZSBzb21lIGRheSBESURDb21tIGNvdWxkIGJlIHVzZWZ1bCBhcyBhIGJhc2ljIGJsb2NrLCB3aGF0 IHdlIHN1Z2dlc3QgaXMgdG8gZmlyc3QgdXNlIHRoYXQgYXMgYSBwb3RlbnRpYWwgaW50ZXJhY3Rp b24gKGFuZCB0aGVyZSdzIGFscmVhZHkgYSBsb3Qgb2YgcXVlc3Rpb25zIHRoYXQgYXJpc2UganVz dCBmcm9tIHRoYXQpLg0KDQpGYWJpZW4NCg0KT24gRnJpLCBGZWIgNSwgMjAyMSBhdCA2OjU1IFBN IFRvbSBKb25lcyA8dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbTxtYWlsdG86dGhvbWFzY2xp bmdhbmpvbmVzQGdtYWlsLmNvbT4+IHdyb3RlOg0KTm8sIHlvdSBkaWRuJ3QgbWlzdW5kZXJzdGFu ZCBtZS4gSXQncyBqdXN0IHRoYXQgdGhlIHV4IGZvciB0aGF0IGlzIG5vdCBhY2NlcHRhYmxlIHRv IHJldGFpbCB1c2Vycy4gQXMgbG9uZyBhcyBnbmFwIHN0aWNrcyB0byBpbmR1c3RyaWFsIHVzZXJz IHlvdSBzaG91bGQgZG8gZmluZS4NCg0KdGh4IC4uVG9tIChtb2JpbGUpDQoNCk9uIEZyaSwgRmVi IDUsIDIwMjEsIDc6NTYgQU0gRmFiaWVuIEltYmF1bHQgPGZhYmllbi5pbWJhdWx0QGdtYWlsLmNv bTxtYWlsdG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPj4gd3JvdGU6DQpUYXJnZXRpbmcgZXhp c3RpbmcgYnJvd3NlcnMgYW5kIHR5cGVzIG9mIGFwcGxpY2F0aW9ucyAod2ViLCBwd2EsIG1vYmls ZSwgZXRjLikgc2VlbXMgbGlrZSBhIHJlYXNvbmFibGUgb3B0aW9uIGZvciBhbiBpbmR1c3RyaWFs IHN0YW5kYXJkLiBJbXByb3Zpbmcgc2VjdXJpdHksIHByaXZhY3ksIGVhc2Ugb2YgdXNlIGFuZCBp bnRlcm9wZXJhYmlsaXR5IChpbmNsdWRpbmcgZGVjZW50cmFsaXplZCBpZGVudGl0eSBhcyB3ZWxs KSBzaG91bGQgYmUgZ29vZCBlbm91Z2ggb2JqZWN0aXZlcy4NClBsdXMgZnJvbSBvdXIgcHJldmlv dXMgZGlzY3Vzc2lvbnMsIEkgd2FzIHVuZGVyIHRoZSBpbXByZXNzaW9uIHlvdSB3ZXJlIGZpbmUg d2l0aCB0aGUgYXBwcm9hY2ggb2YgZGVwbG95aW5nIHRoZSBBUyBvbiB0aGUgcGhvbmUgYXMgYSBs b29wYmFjaywgZm9yIG1vYmlsZSBhcHBzLiBEaWQgSSBtaXNzIHNvbWV0aGluZz8NCg0KQ2hlZXJz LA0KRmFiaWVuDQoNCkxlIHZlbi4gNSBmw6l2ci4gMjAyMSDDoCAxNjozMywgVG9tIEpvbmVzIDx0 aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tPG1haWx0bzp0aG9tYXNjbGluZ2Fuam9uZXNAZ21h aWwuY29tPj4gYSDDqWNyaXQgOg0KSWYgeW91IG1lYW4gY2FuIEdOQVAgd29yayBvbiBvbGQgZmFz aGlvbmVkIGFwcHMgcnVubmluZyB3aXRoIGV4aXN0aW5nIGJyb3dzZXJzIGFuZCBleGlzdGluZyBp ZGVudGl0eSBwcm92aWRlcnMsIHRoZW4geWVzLCBpIGd1ZXNzIHlvdSBhcmUgb2suDQoNCklmIHlv dSB3YW50IHRvIHdvcmsgb24gYXBwcyB3aGVyZSB0aGUgdXNlciBpcyBpbiBjb250cm9sIG9mIGF1 dGhuIGFuZCBhdXRoeiwgdGhlbiBubywgR05BUCBjYW5ub3Qgd29yay4gSXQgaXMgbm90IGFsb25l IGluIHRoYXQgT0lEQyB3b250IHdvcmsgdGhlcmUgZWl0aGVyLg0KDQpCZSB0aGUgY2hhbmdlIHlv dSB3YW50IHRvIHNlZSBpbiB0aGUgd29ybGQgLi50b20NCg0KDQpPbiBGcmksIEZlYiA1LCAyMDIx IGF0IDM6MTkgQU0gRmFiaWVuIEltYmF1bHQgPGZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbTxtYWls dG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBUb20sDQoNClRoYW5rcywg eW91ciByZXNwb25zZXMgbWFkZSBpdCBjbGVhcmVyIGZvciBtZSB3aGF0IHlvdSBleHBlY3QgZnJv bSBhbiBBUyBkZXBsb3llZCBvbiBhIG1vYmlsZS4NCg0KSSB0aGluayB3ZSdyZSBvbiB0aGUgcmln aHQgcGF0aCB0byBtZWV0IHRoZSByZXN0IG9mIHlvdXIgY29uY2VybnMuIFRoZXJlIGFyZSBhbHJl YWR5IGEgZmV3IGl0ZW1zIG9uIHRoZXNlOg0KLSBwcml2YWN5IHByZXNlcnZpbmcgdGVjaG5pcXVl cyBoYXZlIGJlZW4gZGlzY3Vzc2VkIGFuZCBhcmUgbGlrZWx5IHRvIGJlIGluY2x1ZGVkIChJIHRo aW5rKS4gSXQncyBiZWVuIHJlY29nbml6ZWQgYXMgYSBjb3JlIGNvbmNlcm4NCi0gbm90IGV4YWN0 bHkgc3VyZSB0aGUgbWVhbmluZyB5b3UgZ2l2ZSB0byBkaXNjb3ZlcnkgaGVyZSAoaXQncyBhbHJl YWR5IGJlZW4gdXNlZCBpbiB0aGUgV0cgYnV0IHdpdGggYSBkaWZmZXJlbnQgbWVhbmluZyBJIGJl bGlldmUpLiBUaGUgcmVxdWVzdCBvciB0aGUgY29udGludWF0aW9uIGFwaSBwcm92aWRlIGVudHJ5 IHBvaW50cyB0byBwYXkgYXR0ZW50aW9uIHRvLg0KDQpJcyB0aGF0IGVub3VnaCBmb3IgeW91ciB1 c2UgY2FzZSA/IERvIHlvdSBuZWVkIHNvbWV0aGluZyBlbHNlID8gKGxpa2UgU1NFPykNCg0KQ2hl ZXJzDQpGYWJpZW4NCg0KTGUgamV1LiA0IGbDqXZyLiAyMDIxIMOgIDIyOjEwLCBUb20gSm9uZXMg PHRob21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb208bWFpbHRvOnRob21hc2NsaW5nYW5qb25lc0Bn bWFpbC5jb20+PiBhIMOpY3JpdCA6DQpkaXNjb3ZlcnkgaXMgdGhlIHByaW1lIHByb2JsZW0uICBX aGF0IGNhdXNlcyB0aGUgd2FsbGV0L0FTIHRvIHdha2UgdXAgYW5kIHBheSBhdHRlbnRpb24uIEhv dyBkb2VzIHRoZSBSUCBrbm93IHdoYXQgdG8gYXNrIGZvciB3aXRob3V0IHZpb2xhdGluZyB1c2Vy IHByaXZhY3kgcmlnaHRzPw0KDQpDSEFQSSB3b3VsZCBiZSBvayBpIGd1ZXNzLCBidXQgdGhhdCBy ZXF1aXJlcyBjcmVkIG1hbiB0byBiZSBmaXhlZC4gTm90IHN1cmUgaWYgaXQgZml4ZXMgZGlzY292 ZXJ5IG9yIHByaXZhY3kgZXZlbiB0aGVuLg0KDQpCZSB0aGUgY2hhbmdlIHlvdSB3YW50IHRvIHNl ZSBpbiB0aGUgd29ybGQgLi50b20NCg0KDQpPbiBUaHUsIEZlYiA0LCAyMDIxIGF0IDEyOjQ1IFBN IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4g d3JvdGU6DQpUb20sIHdoYXQgYWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5IGRvIHlvdSBzZWUgdGhh dCBhIGJyb3dzZXIgd291bGQgbmVlZCB0byBzdXBwb3J0IGluIG9yZGVyIGZvciBHTkFQIHRvIGJl IGFkb3B0ZWQ/IEZvciB0aGUgZWxlbWVudHMgb2YgdGhlIGNvcmUgcHJvdG9jb2wgdG9kYXksIG5v dGhpbmcgaXMgbmVlZGVkIHRvIGNoYW5nZSB3aXRoaW4gdGhlIGJyb3dzZXJzIOKAlCBldmVyeXRo aW5nIGlzIGJ1aWx0IG9uIGV4aXN0aW5nIGZ1bmN0aW9ucy4gR05BUCB1c2VzIGJyb3dzZXJzIGFz IGEgdG9vbCwgYW5kIEkgd291bGQgYXJndWUgZGVwZW5kcyBvbiB0aGVtIGV2ZW4gbGVzcyBzbyB0 aGFuIE9BdXRoIDIgZG9lcy4gRXh0ZW5zaW9ucyBjb3VsZCB1c2UgYnJvd3NlciBmdW5jdGlvbmFs aXR5LCBsaWtlIHVzaW5nIENIQVBJIHRvIHBhc3MgaW50ZXJhY3Rpb24gZWxlbWVudHMsIGJ1dCB0 aGUgY29yZSBwcm90b2NvbCBmdW5jdGlvbnMgb24gdmFuaWxsYSBicm93c2VycyB0b2RheS4NCg0K IOKAlCBKdXN0aW4NCg0KT24gRmViIDQsIDIwMjEsIGF0IDM6MjAgUE0sIFRvbSBKb25lcyA8dGhv bWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbTxtYWlsdG86dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWls LmNvbT4+IHdyb3RlOg0KDQppIGFzc3VtZWQgdGhhdCB0aGUgd2FsbGV0IChha2EgQVMpIG5lZWRl ZCB0byBiZSBhIG5hdGl2ZSBhcHAsIG5vdCBhIFBXQSAod2hpY2ggY2FuIGNvbWUgZnJvbSBhIHRy YWRpdGlvbmFsIHdlYiBzZXJ2ZXIpLg0KVGhlcmUgYXJlIGZvbGtzLCBsa2UgS2ltIEMsIHdobyBh cmUgd29ya2luZyBvbiBhIFBXQSwgYnV0IGkgYWdyZWUgdGhlIGJsb2NrcyB0aGVyZSBzZWVtIHRv IGJlIGxhcmdlLg0KVEhlIGJsb2NrcyBvbiBhIG5hdGl2ZSBhcHAgYXJlIHNpbXBsZSwgZWFzeSB0 byBkZXNjcmliZSwgYW5kIGVhc3kgdG8gYXNrIHRoZSBicm93c2VyIGd1eXMgdG8gZml4LiBOb3Qg c3VyZSBpZiB0aGV5IGNhcmUgdGhvLg0KSSBoYXZlIHRyb3VibGUgc2VlaW5nIGEgcGF0aCB0byBH TkFQIGFkb3B0aW9uIGZvciByZXRhaWwgY3VzdG9tZXJzIHcvbyBzb21lIGJyb3dzZXIgc3VwcG9y dC4NClRoYXQncyB3aHkgaSBhbSBtb3N0bHkgc2lsZW50IGhlcmUuDQoNCkJlIHRoZSBjaGFuZ2Ug eW91IHdhbnQgdG8gc2VlIGluIHRoZSB3b3JsZCAuLnRvbQ0KDQoNCk9uIFRodSwgRmViIDQsIDIw MjEgYXQgMTE6NDMgQU0gRmFiaWVuIEltYmF1bHQgPGZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbTxt YWlsdG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPj4gd3JvdGU6DQpGYWlyIGVub3VnaC4gQnV0 IGxvb3BiYWNrIGxpbWl0cyBhIGxvdCB3aGF0IHlvdSBjYW4gZG8uLi4gSnVzdCBmb3IgZGVidWcg aXQncyBhIHBhaW4uDQpCdXQgYXMgc29vbiBhcyB5b3UgdHJ5IG1vcmUsIGl0J3MgYSBiaXQgY3Jh enkuIEZ1biB0byB0ZXN0IGlwdjYgKGx1Y2tpbHkgc3VwcG9ydGVkIGJ5IG15IElTUCkgYW5kIGRk bnMuIEJ1dCBpdCBmZWVscyByZWFsbHkgaGFja3kuDQpBbHNvIGRlcGxveW1lbnQgaXMgYSBwYWlu LCBjb21wYXJlZCB0byBhIHRyYWRpdGlvbmFsIHdlYnNlcnZlci4NCg0KTGUgamV1LiA0IGbDqXZy LiAyMDIxIMOgIDIwOjIwLCBUb20gSm9uZXMgPHRob21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb208 bWFpbHRvOnRob21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb20+PiBhIMOpY3JpdCA6DQpkb2Vzbid0 IHdvcmsgdmVyeSB3ZWxsIG9uIHdpbmRvd3MgdXdwLiB3b3JrcyBmaW5lIG9uIHNtYXJ0cGhvbmVz DQpCZSB0aGUgY2hhbmdlIHlvdSB3YW50IHRvIHNlZSBpbiB0aGUgd29ybGQgLi50b20NCg0KDQpP biBUaHUsIEZlYiA0LCAyMDIxIGF0IDExOjE4IEFNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0 LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQpPSywgdGhhbmtzIOKAlCBpbiB0 aGF0IGNhc2UsIHRoZXJlIGFyZSBubyBjaGFuZ2VzIGF0IGFsbCB0byBHTkFQLCB3aGljaCBpcyBh bHJlYWR5IEhUVFAgZHJpdmVuLiBUaGUgaGFyZGVyIHBhcnRzIHRlbmQgdG8gYmUgd2hlcmUgeW91 IGNhbuKAmXQgKG9yIGRvbuKAmXQgd2FudCB0bykgdXNlIHNvbWV0aGluZyBsaWtlIHRoYXQuDQoN CiDigJQgSnVzdGluDQoNCk9uIEZlYiA0LCAyMDIxLCBhdCAyOjE2IFBNLCBUb20gSm9uZXMgPHRo b21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb208bWFpbHRvOnRob21hc2NsaW5nYW5qb25lc0BnbWFp bC5jb20+PiB3cm90ZToNCg0KeWVzLCBsb29wYmFjaw0KDQpCZSB0aGUgY2hhbmdlIHlvdSB3YW50 IHRvIHNlZSBpbiB0aGUgd29ybGQgLi50b20NCg0KDQpPbiBUaHUsIEZlYiA0LCAyMDIxIGF0IDEx OjAxIEFNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQu ZWR1Pj4gd3JvdGU6DQpUb20sIGNhbiB5b3UgZXhwYW5kIG9uIGhvdyBleGFjdGx5IHRoZSBiYWNr LWNoYW5uZWwgIGNvbW11bmljYXRpb24gd29ya3MgYmV0d2VlbiBvbi1kZXZpY2UgY29tcG9uZW50 cz8gRG8geW91IHVzZSBIVFRQIGxvY2FsbHk/DQoNClRoYW5rcywNCiDigJQgSnVzdGluDQoNCk9u IEZlYiA0LCAyMDIxLCBhdCAxOjAzIFBNLCBUb20gSm9uZXMgPHRob21hc2NsaW5nYW5qb25lc0Bn bWFpbC5jb208bWFpbHRvOnRob21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb20+PiB3cm90ZToNCg0K SnVzdGluJ3MgYW5hbHlzaXMgb2YgdXNlIG9mIHRoZSBmcm9udCBjaGFubmVsIGlzIG1pc2xlYWRp bmcuDQpJdCBjb3VsZCBlcXVhbGx5IGJlIGFyZ3VlZCB0aGF0IHdoYXQgaSBoYXZlIGRvbmUgaXMg aW5zdGFsbGVkIGFuIEFTIG9uIHRoZSBwaG9uZSBhbmQgdGhlIGNvbW11bmljYXRpb25zIHdpdGgg aXQgJiB0aGUgUFIgaXMgYmFjayBjaGFubmVsLg0KQmFzaWNhbGx5IHRoZSBwb2ludCBpcyB0aGF0 IHRoZSBvbGQgT0lEQyBwYXJhZGlnbXMgYXJlIG5vIGxvbmdlciB2YWxpZC4NCkJlIHRoZSBjaGFu Z2UgeW91IHdhbnQgdG8gc2VlIGluIHRoZSB3b3JsZCAuLnRvbQ0KDQoNCk9uIFRodSwgRmViIDQs IDIwMjEgYXQgNzo0NyBBTSBGYWJpZW4gSW1iYXVsdCA8ZmFiaWVuLmltYmF1bHRAZ21haWwuY29t PG1haWx0bzpmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb20+PiB3cm90ZToNClllcywgaXNzdWUgKCMx NjgpIG1lc3NhZ2UgYmFzZWQgaW50ZXJhY3Rpb24gLyBESURDb21tIGlzIGEgdGVudGF0aXZlIGFs dGVybmF0aXZlIG1lY2FuaXNtIGZvciB0aGUgaW50ZXJhY3Rpb24gcGFydC4gTm90IHN1cmUgaG93 IHRoYXQgd291bGQgd29yayBpbiBkZXRhaWxzIHRob3VnaCwgcHJvdG90eXBpbmcgd2lsbCBwcm9i YWJseSBoZWxwIGhlcmUuDQpUb2tlbiBkZWxpdmVyeSB0aHJvdWdoIGNvbnRpbnVhdGlvbiBzZWVt cyBmaW5lIHRvIG1lLiBUaGUgY2xpZW50IHdpbGwgcHJvYmFibHkgaGF2ZSB0byB3YWl0IGZvciB0 aGUgbmV4dCBwb2xsaW5nIGJlZm9yZSBpdCByZWNlaXZlcyBhIHRva2VuIGlzc3VlZCBhcyB0aGUg cmVzdWx0IG9mIGFuIGFzeW5jaHJvbm91cyBpbnRlcmFjdGlvbiwgYnV0IHRoYXQncyBub3QgYSBi aWcgaXNzdWUuDQoNCkJ1dCB0aGUgQVMgb24gdGhlIHBob25lIHNlZW1zIGxpa2UgYSBoYXJkZXIg bnV0IHRvIGNyYWNrLCBhdCBsZWFzdCBhdCBmaXJzdCBzaWdodC4gSSB0aGluayB0aGF0IHdvdWxk IGJlIGF3ZXNvbWUsIGJ1dCBpdCBnaXZlcyBtZSBoZWFkYWNoZXMsIHNvIEkgdGhpbmsgSSdsbCB3 b3JrIG9uIGVhc2llciBzdHVmZiByaWdodCBub3cgOy0pDQoNCkZhYmllbg0KDQpPbiBUaHUsIEZl YiA0LCAyMDIxIGF0IDQ6MzAgUE0gSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0 bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCk9uZSBvZiB0aGUgYmlnZ2VzdCBkcmF3YmFja3Mg b2YgdGhlIGN1cnJlbnQgYXBwLWNlbnRyaWMgYXBwcm9hY2hlcyBpbiBPSURDIChzZWxmLWlzc3Vl ZCBPUCwgb3IgU0lPUCkgaXMgdGhhdCB0aGV5IGRlcGVuZCBvbiB1c2luZyB0aGUgZnJvbnQgY2hh bm5lbCBhbmQgYnJvd3NlciByZWRpcmVjdHMgdG8gcGFzcyBldmVyeXRoaW5nLCB3aGljaCBpcyBz b21ldGhpbmcgdGhhdCBHTkFQIGlzIGRlbGliZXJhdGVseSBnZXR0aW5nIGF3YXkgZnJvbSBieSBz dGFydGluZyBpbiB0aGUgYmFjayBjaGFubmVsLg0KDQpUaGF0IHNhaWQsIG9uY2UgYSByZXF1ZXN0 IGlzIGtpY2tlZCBvZmYgaW4gR05BUCwgdGhlIGludGVyYWN0aW9uIGFuZCBmdWxmaWxsbWVudCBj YW4gaGFwcGVuIHRocm91Z2ggYW55IG51bWJlciBvZiBtZWFucy4gUGFydCBvZiB0aGUgd29yayB0 aGF04oCZcyBiZWluZyBkb25lIHdpdGggdGhlIOKAnGludGVyYWN0aW9u4oCdIHNlY3Rpb24gaXMg Z29pbmcgdG8gaGVscCBmYWNpbGl0YXRlIHRoaXMsIGFuZCBJIHRoaW5rIHRoYXQgdGhlcmUgYXJl IHNvbWUgb3RoZXIgcG90ZW50aWFsIGJyYW5jaGVzIGhlcmUuDQoNClRva2VuIGRlbGl2ZXJ5IGlz IHdoZXJlIHRoaW5ncyBnZXQgZXh0cmEgd2VpcmQgdGhvdWdoIOKAlCB3ZSBhcmUgZXhwbGljaXRs eSBub3QgZGVsaXZlcmluZyB0b2tlbnMgaW4gdGhlIGZyb250IGNoYW5uZWwgaW4gdGhlIGNvcmUg b2YgR05BUCwgd2XigJlyZSB1c2luZyB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgY29udGludWF0aW9u IEFQSS4gT25lIGlkZWEgKHRoYXQgaXNu4oCZdCBwYXJ0aWN1bGFybHkgd2VsbCB0aG91Z2h0IG91 dCBhbmQgaGFzbuKAmXQgYmVlbiBpbXBsZW1lbnRlZCBhdCBhbGwpIGlzIHRvIGhhdmUgYW4gZXh0 ZW5zaW9uIGRlY2xhcmUgYW4gYWx0ZXJuYXRpdmUgcmVzcG9uc2UgZnJvbSB0aGUg4oCcY29udGlu dWXigJ0gc2VjdGlvbiB0aGF04oCZcyBkZWZpbmVkIHRvZGF5LCB3aGljaCBwb2ludHMgdG8gdGhl IEdOUEEgY29udGludWF0aW9uIEFQSS4gSWYgYW4gZXh0ZW5zaW9uIGRlZmluZXMgc29tZSBhbHRl cm5hdGl2ZSB3YXkgdG8gZGVsaXZlciB0b2tlbnMsIHRoYXQgY291bGQgbGl2ZSBhbG9uZ3NpZGUg YSBjb250aW51YXRpb24gQVBJIGFuZCB0aGUgY2xpZW50IGNvdWxkIGluZGljYXRlIHN1cHBvcnQg Zm9yIGl0IGluIGl0cyBpbml0aWFsIHJlcXVlc3QuDQoNCkluIGFueSBldmVudCwgYWx0ZXJuYXRp dmUgaW50ZXJhY3Rpb24gYW5kIGRlbGl2ZXJ5IG1ldGhvZHMgYXJlIGltcG9ydGFudCwgYW5kIGV2 ZW4gaWYgd2UgYXJlbuKAmXQgZ29pbmcgdG8gc3VwcG9ydCBldmVyeSBsYXN0IG9uZSBvZiB0aGVt IGRpcmVjdGx5LCB0aGUgcHJvdG9jb2wgZGVzaWduIHNob3VsZCBhdCBsZWFzdCBiZSBhd2FyZSBv ZiB0aGVtLg0KDQog4oCUIEp1c3Rpbg0KDQpPbiBGZWIgNCwgMjAyMSwgYXQgODozNSBBTSwgRmFi aWVuIEltYmF1bHQgPGZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbTxtYWlsdG86ZmFiaWVuLmltYmF1 bHRAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhpIFRvbSwNCg0KU3VyZSwgYW55IGV4cGVyaWVuY2Ug b24gdGhhdCB3b3VsZCBiZSBncmVhdGx5IGFwcHJlY2lhdGVkLCB3ZSdyZSBjYWxsaW5nIGZvciBo ZWxwIGhlcmUgKHRoZSBwb2ludCBiZWluZyB0aGF0IEkgc3VzcGVjdCB3aGF0IHRoZXkncmUgZG9p bmcgaXMgbm90IHRyaXZpYWwpLg0KDQpGYWJpZW4NCg0KT24gVGh1LCBGZWIgNCwgMjAyMSBhdCAy OjIxIFBNIFRvbSBKb25lcyA8dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbTxtYWlsdG86dGhv bWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbT4+IHdyb3RlOg0KSSd2ZSBoYWQgc3VjaCBhbiBhcHAg d29ya2luZyBmb3Igb3ZlciBhIHllYXIuIFRoZXJlIGFyZSBpc3N1ZXMgd2hpY2ggYXJlIGJlaW5n IGFkZHJlc3NlZCBieSB0aGUgYnJvd3NlciBJbnRlcmFjdGlvbiB0ZWFtIG9mIG9pZGMuDQoNCnRo eCAuLlRvbSAobW9iaWxlKQ0KDQpPbiBUaHUsIEZlYiA0LCAyMDIxLCAzOjEyIEFNIEZhYmllbiBJ bWJhdWx0IDxmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb208bWFpbHRvOmZhYmllbi5pbWJhdWx0QGdt YWlsLmNvbT4+IHdyb3RlOg0KSGkgRnJhbmNpcywNCg0KSSd2ZSB0cmllZCBhIGZldyB0aGluZ3Mg d2l0aCByZWdhcmRzIHRvIHVzaW5nIHRoZSBBUyBvbiBhIHBob25lLCBidXQgaXQncyByZWFsbHkg cXVpdGUgY29tcGxleC4NCg0KTWFraW5nIHRoYXQgcnVuIG9uIGEgcGhvbmUgY29tZXMgd2l0aCBx dWl0ZSBhIGJpdCBvZiB0cm91YmxlLiBUaGUgbW9zdCBkaWZmaWN1bHQgcGFydCBpZiB0aGF0IHdl J2QgbmVlZCB0byB1c2UgYSBzZWN1cmUgZWxlbWVudCwgYnV0IGp1c3QgaW5zdGFsbGluZyBhbmQg aG9zdGluZyBhIGh0dHAgc2VydmVyIHNlY3VyZWx5IGlzIG5vdCBhIHN0YW5kYXJkIHNldHVwIGF0 IGFsbC4gSSBzdWdnZXN0IGludGVyZXN0ZWQgcGVvcGxlIHN0ZXAgaW4gdG8gd29yayBvbiB0aGlz LCBhcyB3ZSBhbHJlYWR5IGhhdmUgYSBsb3Qgb2Ygd29yayBmb3IgdGhlIChtb3JlIHVzdWFsKSBz ZXJ2ZXIgY2FzZSBhbmQgYWxyZWFkeSBoYW5kbGUgYSBwcml2YWN5IHByZXNlcnZpbmcgc2NoZW1l Lg0KDQpQbGVhc2UgbGV0IHVzIGtub3cgd2hhdCB5b3UgdGhpbmsuDQoNCkNoZWVycywNCkZhYmll bg0KDQpPbiBUdWUsIE5vdiAyNCwgMjAyMCBhdCA1OjU1IEFNIEZhYmllbiBJbWJhdWx0IDxmYWJp ZW4uaW1iYXVsdEBnbWFpbC5jb208bWFpbHRvOmZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbT4+IHdy b3RlOg0KSGkgRnJhbmNpcywNCg0KSSd2ZSB0aG91Z2h0IGEgYml0IG1vcmUgdG8gd2hhdCB5b3Ug c2FpZC4gSSB0aGluayBJJ2xsIGdpdmUgaXQgYSB0cnkgYXMgYSBzZXBhcmF0ZSBleHBlcmltZW50 IChpbiBjb2RlLCBub3QgaW4gdGhlb3J5KS4gTm90IHRoYXQgSSB3b3VsZCBleHBlY3QgaXQgdG8g YmUgaW5jbHVkZWQgaW4gR05BUCwgYnV0IEkga2luZCBvZiBsaWtlIHRoZSBpZGVhIDotKQ0KDQpU aGUgZGlyZWN0IGltcGFjdCBmb3IgR05BUCB3b3VsZCBiZSB0byB0aGluayBhYm91dCBtdWx0aXBs ZSBBU3MuDQoNCldpbGwgbGV0IHlvdSBrbm93Lg0KDQpGYWJpZW4NCg0KDQpMZSBtZXIuIDE4IG5v di4gMjAyMCDDoCAxMzowNiwgRnJhbmNpcyBQb3VhdGNoYSA8ZnBvQGFkb3JzeXMuZGU8bWFpbHRv OmZwb0BhZG9yc3lzLmRlPj4gYSDDqWNyaXQgOg0KSXQgd291bGQgYmUgbmljZSBpZiB0aGUgcHJv dG9jb2wgd2FzIGRlc2lnbmVkIGF0IG1hbnkgbGF5ZXJzIG9mIGFic3RyYWN0aW9uLg0KDQoNCiAg KiAgIFRoZSBmaXJzdCBsYXllciBzaGFsbCBkZXNpZ24gYWJzdHJhY3QgcHJvdG9jb2wgZmxvd3Ms IHdpdGhvdXQgc3BlY2lmaWNhdGlvbiBvZiB0aGUgbW9kZSBhbmQgbWVjaGFuaXNtIG9mIGludGVy YWN0aW9uLg0KICAqICAgVGhlIHNlY29uZCBsYXllciBjYW4gaW5zdGFudGlhdGUgdGhlIGZpcnN0 IGxheWVyIGZvciBkZWRpY2F0ZWQgaW50ZXJhY3Rpb24uIEhlcmUgd2UgY2FuIHRhbGsgaHR0cCwg d2UgY2FuIGRlZmluZSBpbnRlcmFjdGlvbnMgdGhhdCBwcmVzdW1lIHNlcnZlciBiYXNlZCB0b2tl biBnZW5lcmF0aW9uLCB3ZSBjYW4gZGVmaW5lIGludGVyYWN0aW9uIHRoYXQgcnVuIG9uIHVzZXIg ZGV2aWNlIGJhc2VkIHRva2VuIGdlbmVyYXRpb24uDQoNClRoaXMgaXMgYWxzbyB0aGUgZnVuZGFt ZW50IG9mIHRoZSBzdHJ1Y3R1cmUgSSBwcm9wb3NlZCBmb3IgdGhlIHNwZWMgKGh0dHBzOi8vZ2l0 aHViLmNvbS9pZXRmLXdnLWduYXAvZ25hcC1jb3JlLXByb3RvY29sL2lzc3Vlcy8zMCkuDQoNCi9G cmFuY2lzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBGYWJpZW4g SW1iYXVsdCA8ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPG1haWx0bzpmYWJpZW4uaW1iYXVsdEBn bWFpbC5jb20+Pg0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxOCwgMjAyMCA2OjM1IEFNDQpU bzogRnJhbmNpcyBQb3VhdGNoYSA8ZnBvQGFkb3JzeXMuZGU8bWFpbHRvOmZwb0BhZG9yc3lzLmRl Pj4NCkNjOiB0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aEBpZXRmLm9yZz4gPHR4YXV0aEBp ZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPj47IERpY2sgSGFyZHQgPGRpY2suaGFyZHRA Z21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+OyBUb20gSm9uZXMgPHRob21h c2NsaW5nYW5qb25lc0BnbWFpbC5jb208bWFpbHRvOnRob21hc2NsaW5nYW5qb25lc0BnbWFpbC5j b20+PjsgRGVuaXMgPGRlbmlzLmlldGZAZnJlZS5mcjxtYWlsdG86ZGVuaXMuaWV0ZkBmcmVlLmZy Pj47IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1 Pj4NClN1YmplY3Q6IFJlOiBbR05BUF0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtZ25hcC1jb3JlLXBy b3RvY29sLTAwDQoNCldvdWxkIG1ha2Ugc2Vuc2UsIGJ1dCBub3Qgc28gZWFzeSBhcyB3ZSByZWx5 IGhlYXZpbHkgb24gSFRUUC4gSGVuY2UgdGhlIGRpc2N1c3Npb24gYWJvdXQgZGVlcCBsaW5rcyBh bmQgc28gb24uDQoNCkFuIGFsdGVybmF0aXZlIG1pZ2h0IGJlIHByb3ZpZGVkIGJ5IHdhc20vd2Fz aSAocnVubmluZyBhIGxvY2FsIHNhbmRib3ggb24geW91ciBwaG9uZSwgZm9yIHlvdXIgb3duIEFT KSwgYnV0IGl0J3MgcmVhbGx5IGVhcmx5IHN0YWdlLiBUaGlzIGFsc28gcG9zZXMgYW5vdGhlciBx dWVzdGlvbiB0aGF0IERlbmlzIGhhcyBwdXQgZm9yd2FyZCwgaS5lLiBob3cgZG8gd2UgaGFuZGxl IHRoZSBtdWx0aXBsZSBBUyBzY2VuYXJpbyAobGlrZWx5IHRvIG9jY3VyIHRoZW4pLg0KDQpGYWJp ZW4NCg0KT24gV2VkLCBOb3YgMTgsIDIwMjAgYXQgMTI6MTYgUE0gRnJhbmNpcyBQb3VhdGNoYSA8 ZnBvQGFkb3JzeXMuZGU8bWFpbHRvOmZwb0BhZG9yc3lzLmRlPj4gd3JvdGU6DQpXZSBhcmUgZHJp ZnRpbmcgYXdheSBmcm9tIHRoZSBvcmlnaW5hbCBwcm9ibGVtIHNwYWNlLg0KDQogICogICBNeSBv cmlnaW5hbCBtZW50aW9uIHdhcyBhYm91dCB0aGUgIlBPU1QiIHJlcXVlc3QsIHRoYXQgc3Vic3Vt ZXMgdGhhdCB0aGUgIkFTIiBpcyBhICJTZXJ2ZXIiLiBEZXNpZ25pbmcgYSBuZXcgcHJvdG9jb2ws IHdlIGNhbm5vdCBhZmZvcmQgdGhpcyBsaW1pdGF0aW9uLg0KICAqICAgSSBqdXN0IG1lbnRpb25l ZCBTSU9QIHRvIHNob3cgYSBrbm93biBhbmQgY2xvc2VkIGV4YW1wbGU/IExldCB1cyBub3QgZm9j dXMgb24gdGhlIGRldmljZSBsb2NhbCBkaXNjb3Zlcnkgc2NoZW1lIChsaWtlIG9wZW5pZDopIGZv ciBub3cuDQogICogICBBcyBjYXBhYmlsaXR5IG9mIGhvbGRpbmcgcHJpdmF0ZSBrZXlzIG9uIHVz ZXIgZGV2aWNlIGV2b2x2ZXMsIHNlcnZlci1iYXNlZCBpc3N1aW5nIG9mIHRva2VuIHdpbGwgYmUg ZmFkaW5nIG91dCBnaXZpbmcgd2F5IHRvIGRldmljZSBsb2NhbCBnZW5lcmF0aW9uIG9mIHRva2Vu Lg0KDQpXaGlsZSBkZXNpZ25pbmcgR05BUCwgbGV0IHVzIGFzc3VtZSB0aGUgQVMtUm9sZSBjYW4g YmUgZXhlcmNpc2VkIG9uIGEgdXNlciBkZXZpY2UgYW5kIGRlc2lnbiB0aGUgcHJvdG9jb2wgdG8g aG9ub3IgdGhhdC4NCg0KQmVzdCByZWdhcmRzLA0KL0ZyYW5jaXMNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpGcm9tOiBUWEF1dGggPHR4YXV0aC1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzp0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0IDxk aWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pg0KU2VudDog VHVlc2RheSwgTm92ZW1iZXIgMTcsIDIwMjAgMToyOCBQTQ0KVG86IFRvbSBKb25lcyA8dGhvbWFz Y2xpbmdhbmpvbmVzQGdtYWlsLmNvbTxtYWlsdG86dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNv bT4+DQpDYzogRmFiaWVuIEltYmF1bHQgPGZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbTxtYWlsdG86 ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPj47IERlbmlzIDxkZW5pcy5pZXRmQGZyZWUuZnI8bWFp bHRvOmRlbmlzLmlldGZAZnJlZS5mcj4+OyBHTkFQIE1haWxpbmcgTGlzdCA8dHhhdXRoQGlldGYu b3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5vcmc+PjsgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQu ZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+Pg0KU3ViamVjdDogUmU6IFtHTkFQXSBSZXZpZXcg b2YgZHJhZnQtaWV0Zi1nbmFwLWNvcmUtcHJvdG9jb2wtMDANCg0KR290IGl0Lg0KDQpTbyB3ZWIg YXBwcyBpbnZva2UgYSBvcGVuaWQ6IGRlZXAgbGluayBhbmQgaG9wZSB0aGVyZSBpcyBhbiBhcHAg dG8gaGFuZGxlIHRoZSBvcGVuaWQ6IHNjaGVtZT8gLi4uIGFuZCB0aGF0IGl0IGlzIHRoZSB1c2Vy J3Mgd2FsbGV0IHJhdGhlciB0aGFuIHNvbWUgbWFsd2FyZSB0aGF0IGhhcyByZWdpc3RlcmVkIG9w ZW5pZDogb24gdGhlIG1vYmlsZSBkZXZpY2U/DQoNCkEgbmF0aXZlIGFwcCBjYW4gYXR0ZW1wdCB0 byBvcGVuIGEgZGVlcCBsaW5rIGFzc29jaWF0ZWQgd2l0aCBhbiBhcHAsIGFuZCB3aWxsIGZhaWwg aWYgdGhlIGFwcCBpcyBub3QgdGhlcmUuIElmIHRoZSBhcHAgaXMgdGhlcmUsIGl0IHdpbGwgYmUg b3BlbmVkLCBzbyB0aGlzIGNhbid0IGJlIHVzZWQgdG8gc2lsZW50bHkgdGVzdCBpZiBhbiBhcHAg aXMgcHJlc2VudCwgYnV0IGl0IGRvZXMgYWxsb3cgYSBuYXRpdmUgYXBwIHRvIHByb3ZpZGUgYW4g YWx0ZXJuYXRpdmUgZXhwZXJpZW5jZSBpZiBhbiBhcHAgaXMgbm90IHByZXNlbnQuIEkgZG9uJ3Qg dGhpbmsgdGhpcyB3b3JrcyB3aXRoIGN1c3RvbSBzY2hlbWVzIC4uLiBhbmQgSSBkb24ndCBrbm93 IGhvdyBpdCBjb3VsZCB3b3JrIGZyb20gYSB3ZWIgYXBwIG9uIHRoZSBwaG9uZSB3aXRoIHRoZSBj dXJyZW50IFNhZmFyaSBBUElzLg0KDQpBcHBsZSB3YXJucyBhZ2FpbnN0IHVzaW5nIGN1c3RvbSBz Y2hlbWVzIFsxXSAuLi4gYnV0IHBlcmhhcHMgdGhleSBjYW4gYmUgY29udmluY2VkIHRvIG1ha2Ug b3BlbmlkOiBhIG1hbmFnZWQgc2NoZW1lIHNpbWlsYXIgdG8gbWFpbHRvOiwgdGVsOiwgc21zOiwg ZmFjZXRpbWU6ID8NCg0KWzFdIGh0dHBzOi8vZGV2ZWxvcGVyLmFwcGxlLmNvbS9kb2N1bWVudGF0 aW9uL3hjb2RlL2FsbG93aW5nX2FwcHNfYW5kX3dlYnNpdGVzX3RvX2xpbmtfdG9feW91cl9jb250 ZW50L2RlZmluaW5nX2FfY3VzdG9tX3VybF9zY2hlbWVfZm9yX3lvdXJfYXBwDQoNCg0KW2h0dHBz Oi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBi QzVqYjIwJTNEJnR5cGU9emVyb2NvbnRlbnQmZ3VpZD0wMTE0OTBiZS1kM2EwLTRiMmMtOGFiYi1l NTExNzVlM2FlMTld4ZCnDQoNCk9uIFR1ZSwgTm92IDE3LCAyMDIwIGF0IDEwOjA2IEFNIFRvbSBK b25lcyA8dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbTxtYWlsdG86dGhvbWFzY2xpbmdhbmpv bmVzQGdtYWlsLmNvbT4+IHdyb3RlOg0KWW91IGFyZSAtIHRoYXQgaXMgbm90IHN0YW5kYXJkIHdo aWNoIGlzIG9wZWluZDovLw0KVGhpcyBpcyB0aGUgb25lIHN0ZXAgdGhhdCBzdGlsbCBuZWVkcyB0 byBiZSBvcHRpbWl6ZWQgZm9yIFNJT1AgdG8gaGF2ZSBnb29kIFVYLg0KUGVhY2UgLi50b20NCg0K DQpPbiBUdWUsIE5vdiAxNywgMjAyMCBhdCA5OjU5IEFNIERpY2sgSGFyZHQgPGRpY2suaGFyZHRA Z21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KSGkgVG9tDQoN Ckkgd2F0Y2hlZCB5b3VyIHZpZGVvIChJIHdhdGNoZWQgYXQgMlggc3BlZWQpDQoNCkxvb2tzIGxp a2UgdGhlIGVtcGxveW1lbnQgd2Vic2l0ZSBhcHAgdGhhdCBpcyB1c2luZyBsb2NhbGhvc3Q6ODc2 NSB0byBjb21tdW5pY2F0ZSB3aXRoIHRoZSB3YWxsZXQuIEFtIEkgY29ycmVjdD8NCg0KL0RpY2sN CltodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RF Qm5iV0ZwYkM1amIyMCUzRCZ0eXBlPXplcm9jb250ZW50Jmd1aWQ9MTFhNjJjZTYtOWI0YS00ZDVm LTg2YzUtZDJjMTE0Mzk1YWVlXeGQpw0KDQpPbiBUdWUsIE5vdiAxNywgMjAyMCBhdCA5OjQ2IEFN IFRvbSBKb25lcyA8dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbTxtYWlsdG86dGhvbWFzY2xp bmdhbmpvbmVzQGdtYWlsLmNvbT4+IHdyb3RlOg0KV2VsbCwgaGVyZSdzIGEgZGVtby4gTm90ZSB0 aGF0IGluIHRoaXMgY2FzZSB0aGUgQVMgaXMgbm90IG9ubGluZSBhbGwgb2YgdGhlIHRpbWUsIHNv IGl0IGlzIHJlYWxseSBpbXBsaWNpdCBmbG93IGFuZCB0aGUgT0lEQyBpZC10b2tlbiBjb21lcyBm cm9tIHRoZSBzaW9wIGRldmljZSBkaXJlY3RseS4NCih3aGV0aGVyIHRoaXMgaXMgZnJvbnQtY2hh bm5lbCBvciBiYWNrIGNoYW5uZWwgaXMgbm8gbG9uZ2VyIGFuIGludGVyZXN0aW5nIHF1ZXN0aW9u LikNCk5vdyBpZiBhbiBhbHdheXMtb24gQVMgaXMgcmVxdWlyZWQsIHRoYXQgaXMgcG9zc2libGUs IGJ1dCBwcm9iYWJseSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZWZmb3J0IGFuZCB3b3VsZCBy ZXF1aXJlIHNvbWV0aGluZyBsaWtlIGFuIGFnZW50LWluLXRoZS1za3kgKHdpdGggZGlhbW9uZHMp Lg0KaGVyZSBpcyB0aGUgbGluayB0byB0aGUgOSBtaW4gdmlkZW8gICBodHRwczovL3lvdXR1LmJl L1RxNGh3N1g1U1cwPGh0dHBzOi8vdXJsZGVmZW5zZS51cy92Mi91cmw/dT1odHRwcy0zQV9feW91 dHUuYmVfVHE0aHc3WDVTVzAmZD1Ed01GYVEmYz0ycGxJM2hYSDh3dzNqMmc4cFYxOVFISWY0U21L X0ktRW9sX3A5UDBDdHRFJnI9RDVsbmZvYTJNVlpXRUxxVmJiejcxb29lbGJQN3JWR0NqR0RTQk52 VXBZUSZtPWl4c3VkR1NyX2RoRy1TTGlhdGI0U3o5RldzbG15d25ZeVpBT0xnWnhobDgmcz1qZExM eTBHMUpUUUNBT0JaNlBlVWdJMGtpQ3RWSlhycnUwVlRvWVdsTlo4JmU9Pg0KUGVhY2UgLi50b20N Cg0KDQpPbiBUdWUsIE5vdiAxNywgMjAyMCBhdCA5OjIwIEFNIEp1c3RpbiBSaWNoZXIgPGpyaWNo ZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQpVbHRpbWF0ZWx5LCBp biBtb3N0IHNpdHVhdGlvbnMgbGlrZSB0aGVzZSBpbiB0aGUgcmVhbCB3b3JsZCwgdGhlIGh1cmRs ZSBpc27igJl0IHRlY2huaWNhbCBjb21wYXRpYmlsaXR5IHNvIG11Y2ggYXMgaXQgaXMgdHJ1c3Qg Y29tcGF0aWJpbGl0eS4gVGhlIFJQIChjbGllbnQpIG5lZWRzIHRvIGhhdmUgc29tZSBpbmNlbnRp dmUgdG8gdHJ1c3QgdGhlIGFzc2VydGlvbnMgYW5kIGlkZW50aXR5IGluZm9ybWF0aW9uIHRoYXTi gJlzIGNvbWluZyBmcm9tIHRoZSBBUy4gVGhlIHNhbWUgaXMgdHJ1ZSBmb3IgYW4gUlMgdHJ1c3Rp bmcgdG9rZW5zIGZyb20gdGhlIEFTLiBUaGUgaGFyZCBxdWVzdGlvbiBpcyBsZXNzIOKAnGhvd+KA nSB0byBkbyB0aGF0ICh3aGljaCBTU0kgYW5zd2VycyksIGJ1dCBtb3JlIOKAnHdoeeKAnSB0byBk byB0aGF0ICh3aGljaCBTU0kgZG9lc27igJl0IGFuc3dlciB2ZXJ5IHdlbGwsIGJlY2F1c2UgaXTi gJlzIGEgaGFyZCBxdWVzdGlvbikuDQoNClN0aWxsOiBpdOKAmXMgZGVmaW5pdGVseSBhIHF1ZXN0 aW9uIGFib3V0IGhvdyB0byBzdXBwb3J0IHRoaXMg4oCcQVMgb24gZGV2aWNl4oCdIGVsZW1lbnQu IFdl4oCZdmUgZ290IHRoZSBzdGFydCBvZiBpdCBtb3JlIHRoYW4gT0F1dGgyL09JREMgaGF2ZSBi eSBhbGxvd2luZyB0aGUgYm9vdHN0cmFwIG9mIHRoZSBwcm9jZXNzIGZyb20gYSBzdGFydGluZyBj YWxsOiB0aGUgaW50ZXJhY3Rpb24gYW5kIGNvbnRpbnVhdGlvbiBVUklzIGhhbmRlZCBiYWNrIGJ5 IHRoZSBBUyBkb27igJl0IG5lZWQgdG8gYmUgdGhlIHNhbWUgVVJJcyB0aGF0IHRoZSBjbGllbnQg c3RhcnRzIHdpdGgsIHNvIGp1c3QgbGlrZSBTSU9QIHRoZSBwcm9jZXNzIGNhbiBzdGFydCBpbiBI VFRQIGFuZCBwb3RlbnRpYWxseSBtb3ZlIHRvIG90aGVyIGNvbW11bmljYXRpb24gY2hhbm5lbHMu IEEgbWFqb3IgZGlmZmVyZW5jZSBpcyB0aGF0IHdlIGFyZW7igJl0IGRlcGVuZGVudCBvbiB0aGUg YXNzdW1wdGlvbiB0aGF0IHRoZSB1c2VyIHdpbGwgYWx3YXlzIGJlIGluIGEgYnJvd3NlciBhdCBz b21lIHN0YWdlLCBhbmQgc28gdGhlIHdob2xlIHJhZnQgb2YgZnJvbnQtY2hhbm5lbCBtZXNzYWdl cyB0aGF0IFNJT1AgcmVsaWVzIG9uIGRvZXNu4oCZdCBmbHkuIFRoYXQgc2FpZCwgd2XigJl2ZSBn b3QgYW4gb3Bwb3J0dW5pdHkgdG8gbW9yZSBleHBsaWNpdGx5IG9wZW4gdXAgYWx0ZXJuYXRpdmUg Y29tbXVuaWNhdGlvbiBjaGFubmVscyBoZXJlLCBhbmQgdGhhdOKAmXMgc29tZXRoaW5nIEnigJlk IGxpa2UgdG8gc2VlIGVuZ2luZWVyZWQsIGV2ZW4gaWYgaXTigJlzIGFuIGV4dGVuc2lvbi4gSeKA mWQgbG92ZSB0byBzZWUgYSBjb25jcmV0ZSBwcm9wb3NhbCBhcyB0byBob3cgdGhhdCB3b3VsZCB3 b3JrIG92ZXIgc3BlY2lmaWMgcHJvdG9jb2xzLCBzdGFydGluZyB3aXRoIHdoYXQgd2XigJl2ZSBn b3QgdG9kYXkuDQoNCiDigJQgSnVzdGluDQoNCk9uIE5vdiAxNywgMjAyMCwgYXQgMTI6MDMgUE0s IEZhYmllbiBJbWJhdWx0IDxmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb208bWFpbHRvOmZhYmllbi5p bWJhdWx0QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBEZW5pcywgaGkgRnJhbmNpcywNCg0KQXQg c29tZSBwb2ludCBpbnRlZ3JhdGlvbiB3aXRoIFNTSSAob24gdGhlIGF1dGhlbnRpY2F0aW9uIHNp ZGUpIHdpbGwgcHJvYmFibHkgb2NjdXIsIGluY2x1ZGluZyBhbW9uZ3N0IG90aGVyIHBvc3NpYmls aXRpZXMgU0lPUCAoc2luY2UgdGhleSB3b3JrIHdpdGggT3BlbklEIGEgcGFydCBvZiB0aGUgd29y ayB3aWxsIHByb2JhYmx5IGJlIG1hZGUgZWFzaWVyKS4NCg0KVGhhdCBiZWluZyBzYWlkLCBEZW5p cyBpcyByaWdodC4gSXQncyBub3QgYW4gQVMuIFRlY2huaWNhbGx5IGl0J3MgZW50aXJlbHkgcG9z c2libGUgdG8gcmVseSBvbiBhIGRlY2VudHJhbGl6ZWQgd2FsbGV0IChmb3IgaW5zdGFuY2Ugb24g eW91ciBwaG9uZSkgYW5kIGEgY2VudHJhbGl6ZWQgQVMuIEkga25vdyBvZiBhIGZldyBzdHVkaWVz IG9uIGhvdyB0byBkZWNlbnRyYWxpemUgdGhlIEFTIGl0c2VsZiAoZm9yIGluc3RhbmNlIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkam9uby1vYXV0aC1kZWNlbnRyYWxpemVk LTAyKS4NCk1heWJlIGl0IGV4aXN0cywgYnV0IEknbSBzdGlsbCBsb29raW5nIGZvciByZWFsIHNj ZW5hcmlvcyAob3IgZXZlbiBhcmNoaXRlY3R1cmVzKSB3aGVyZSBhbiBBUyBpcyBkZXBsb3llZCBk aXJlY3RseSBvbiBhIHBob25lLCBhbmQgdW5kZXIgdGhlIHNvbGUgYXV0aG9yaXR5IG9mIHRoZSBS Tywgd2hpbGUgYmVpbmcgY29tcGF0aWJsZSB3aXRoIHRoZSByZXN0IG9mIHRoZSB3b3JsZC4NCg0K Q2hlZXJzLA0KRmFiaWVuDQoNCk9uIFR1ZSwgTm92IDE3LCAyMDIwIGF0IDU6NDUgUE0gRGVuaXMg PGRlbmlzLmlldGZAZnJlZS5mcjxtYWlsdG86ZGVuaXMuaWV0ZkBmcmVlLmZyPj4gd3JvdGU6DQpI ZWxsbyAgRnJhbmNpcywNCg0KU2VlIHR3byBjb21tZW50cyBpbiBsaW5lLg0KDQoNCkIpIEN1cnJl bnQgRG9jdW1lbnQNCg0KUm9sZXMgZGVzY3JpcHRpb24gc2hhbGwgbm90IGhvbGQgYW55IGFzc3Vt cHRpb24gb24gdGhlIHBoeXNpY2FsIHN0cnVjdHVyZSBvZiB0aGUgcGFydHkgZnVsZmlsbGluZyB0 aGUgcm9sZXMuDQpbRkldIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4NCiBbRlBdIGZvciBleGFtcGxl LCB3ZSBhc3N1bWUgdGhlIEFTIGlzIGEgc2VydmVyISBJbiBtb3N0IFNTSSBiYXNlZCB1c2UgY2Fz ZXMsIHRoZSBBUyB3aWxsIGJlIHJ1bm5pbmcgb24gdGhlIHVzZXIgZGV2aWNlLiBTZWUgU0lPUCAo aHR0cHM6Ly9pZGVudGl0eS5mb3VuZGF0aW9uL2RpZC1zaW9wLykuDQoNCkkgYnJvd3NlZCB0aHJv dWdoIHRoZSB0d28gZHJhZnRzLCBpLmUuIDoNCg0KICAqICAgRGVjZW50cmFsaXplZCBJZGVudGlm aWVycyAoRElEcykgdjEuMCBDb3JlIGFyY2hpdGVjdHVyZSwgZGF0YSBtb2RlbCwgYW5kIHJlcHJl c2VudGF0aW9ucyBXM0MgV29ya2luZyBEcmFmdCAwOCBOb3ZlbWJlciAyMDIwDQogICogICBTZWxm LUlzc3VlZCBPcGVuSUQgQ29ubmVjdCBQcm92aWRlciBESUQgUHJvZmlsZSB2MC4xLiBESUYgV29y a2luZyBHcm91cCBEcmFmdA0KDQpBdCBubyBwbGFjZSB3aXRoaW4gdGhlc2UgdHdvIGRvY3VtZW50 cywgaXQgaXMgcG9zc2libGUgdG8gaW1hZ2luZSB0aGF0ICJ0aGUgQVMgd2lsbCBiZSBydW5uaW5n IG9uIHRoZSB1c2VyIGRldmljZSIuDQoNCkZyb20gc2VjdGlvbiAzIG9mIHRoZSBESUYgV29ya2lu ZyBHcm91cCBEcmFmdDoNCg0KICAgICAgIlVubGlrZSB0aGUgT0lEQyBBdXRob3JpemF0aW9uIENv ZGUgRmxvdyBhcyBwZXIgW09JREMuQ29yZV0sIHRoZSBTSU9QIHdpbGwgbm90IHJldHVybiBhbiBh Y2Nlc3MgdG9rZW4gdG8gdGhlIFJQIi4NCg0KQW4gSWRlbnRpdHkgV2FsbGV0IGlzIG5vdCBhbiBB Uy4NCg0KUm9sZXM6DQotPiBncmFudCBlbmRwb2ludCBvZiB0aGUgQVM6IFdoeSBpcyB0aGlzIGEg cG9zdCByZXF1ZXN0PyBUaGlzIGVsaW1pbmF0ZXMgdGhlIGNoYW5jZSBvZiBoYXZpbmcgdXNlciBk ZXZpY2UgaG9zdGVkIEFTIChubyBzZXJ2ZXIpLg0KW0ZJXSB3aGF0IHdvdWxkIHlvdSBwcm9wb3Nl IGluc3RlYWQ/DQpXb3VsZCBhbHNvIGJlIGludGVyZXN0ZWQgdG8gdW5kZXJzdGFuZCBiZXR0ZXIg dGhlIGRlcGxveW1lbnQgbW9kZWwgd2hlbiB0aGVyZSBpcyBubyBzZXJ2ZXIuIFRoYXQncyBzb21l dGhpbmcgdGhhdCB3YXMgZGlzY3Vzc2VkIHNldmVyYWwgdGltZXMgYnV0IEknbSBzdGlsbCBtaXNz aW5nIHRoZSB1bmRlcmx5aW5nIGFyY2hpdGVjdHVyZSBhbmQgdXNlIGNhc2UuDQogW0ZQXSBTZWUg YWJvdmUgKFNJT1ApLiBUaGVyZSB3aWxsIGJlIGEgbG90IG9mIGlkZW50aXR5IHdhbGxldHMgb3Bl cmF0ZWQgb24gZW5kIHVzZXIgZGV2aWNlLg0KDQpTZWUgdGhlIGFib3ZlIGNvbW1lbnQuIFBsZWFz ZSwgZG8gbm90IGNvbmZ1c2UgYW4gSWRlbnRpdHkgV2FsbGV0IHdpdGggYW4gQXV0aGVudGljYXRp b24gU2VydmVyIChBUykuDQoNCkRlbmlzDQoNCi0+IFJlc291cmNlIE93bmVyIChSTykgOiBBdXRo b3JpemVzIHRoZSByZXF1ZXN0PyBEb2VzIGl0IGF1dGhvcml6ZSB0aGUgcmVxdWVzdCBvciB0aGUg YWNjZXNzIHRvIGEgcmVzb3VyY2U/DQpbRkldIHllcywgd2Ugc2hvdWxkIG1ha2UgdGhlIHdvcmRp bmcgY2xlYXJlcg0KDQpNaXNzaW5nIFNlY3Rpb24gSW50ZXJhY3Rpb25zOg0KLS0+IFRoaXMgc2Vj dGlvbiBzaGFsbCBpbnRyb2R1Y2UgdGhlIG5vdGlvbiBvZiBpbnRlcmFjdGlvbiBiZWZvcmUgd2Ug c3RhcnQgbGlzdGluZyBpbnRlcmFjdGlvbiB0eXBlcy4NCltGSV0geWVzDQoNCkludGVyYWN0aW9u IFR5cGVzOg0KLS0+IEkgcHJlZmVyIGEgY2xhc3NpZmljYXRpb24gd2l0aCBSZWRpcmVjdCwgRGVj b3VwbGVkIGFuZCBFbWJlZGRlZCBpcy4gSW4gdGhlIGRyYWZ0LCB3ZSBoYXZlIG9uZSByZWRpcmVj dCBhbmQgMiBkZWNvdXBsZSBpbnRlcmFjdGlvbnMgYW5kIG5vdGhpbmcgZWxzZS4NCltGSV0gdGhp cyBzaG91bGQgYmUgaGFuZGxlZCBhcyBhIHNwZWNpZmljIGRpc2N1c3Npb24gaXRlbS4gQXMgYSBy ZW1pbmRlciwgaG93IHdvdWxkIHlvdSBkZWZpbmUgZW1iZWRkZWQ/DQoNCkluIHByYWN0aWNlIHRo ZXJlJ3MgYXQgbGVhc3QgdGhlc2UgbW9kZXM6DQotIHJlZGlyZWN0IGFuZCByZWRpcmVjdCBiYWNr DQotIHJlZGlyZWN0IHRvIGRpZmZlcmVudCBicm93c2VyIG9yIGRldmljZQ0KLSB1c2VyIGNvZGUN Ci0gQ0lCQQ0KW0ZQXSBUaGlzIGNsYXNzaWZpY2F0aW9uIGlzIGxpbWl0ZWQuDQoNCiAgKiAgIFJl ZGlyZWN0OiBzYW1lIGRldmljZSwgc2FtZSBvciBkaWZmZXJlbnQgdXNlciBhZ2VudHMgKGJyb3dz ZXIsIG1vYmlsZSBhcHAsIGRlc2t0b3AgYXBwLCAuLi4pDQogICogICBEZWNvdXBsZWQ6IGRpZmZl cmVudCBkZXZpY2VzDQogICogICBFbWJlZGRlZCA6IFJDIGNhcnJpZXMgUk8gYXV0aG9yaXphdGlv biB0byBBUw0KDQoNClJlc291cmNlIEFjY2VzcyBSZXF1ZXN0IHZzLiBSZXNvdXJjZSBSZXF1ZXN0 DQotLT4gQm90aCBhcmUgbWl4ZWQgdXAuIE5vIGNsYXJpZmljYXRpb24gb2YgdGhlIGNvbnRleHQg b2YgZWFjaCBzZWN0aW9uLg0KW0ZJXSBjb3VsZCB5b3UgY2xhcmlmeSB3aGF0IHlvdSdkIGV4cGVj dC4gIEJ0dyBvbiB0aGlzIHRvcGljLCB0aGVyZSdzIGEgbW9yZSBnZW5lcmFsIGRpc2N1c3Npb24g b24gd2hldGhlciB3ZSBzaG91bGQgbWFrZSBhIGRpc3RpbmN0aW9uIG9yIG5vdC4NCltGUF06IEhl cmU6DQoNCiAgKiAgIFJlc291cmNlIEFjY2VzcyBSZXF1ZXN0OiBSZXF1ZXN0aW5nIEFjY2VzcyB0 byBhIHJlc291cmNlLiBSZXNwb25zZSBpcyBhbiBhY2Nlc3MgdG9rZW4gKG9yIGFueSB0eXBlIG9m IGdyYW50KQ0KICAqICAgUmVzb3VyY2UgUmVxdWVzdDogUmVxdWVzdCB0aGUgcmVzb3VyY2UuIFJl c3BvbnNlIGlzIHRoZSByZXNvdXJjZSAob3IgYSBjb3JyZXNwb25kaW5nIGV4ZWN1dGlvbikNCg0K VG9rZW4gQ29udGVudCBOZWdvdGlhdGlvbg0KLS0+IE5vdCBleHByZXNzZWQgYXMgc3VjaC4gVGhp cyBpcyBjZW50cmFsIHRvIEdOQVAgYW5kIG5vdCByZXByZXNlbnRlZCBlbm91Z2ggIGluIHRoZSBk b2N1bWVudC4NCltGSV0gcmlnaHQuIFRoaXMgc2hvdWxkIGJlIGEgc3BlY2lmaWMgZGlzY3Vzc2lv biBpdGVtLg0KDQpSZXF1ZXN0aW5nICJVc2VyIiBJbmZvcm1hdGlvbg0Kd2UgaWRlbnRpZnkgdHdv IHR5cGVzIG9mIHVzZXJzOiBSUSBhbmQgUk8uIEl0IHdpbGwgYmUgYmV0dGVyIG5vdCB0byByZWZl ciB0byBhIHVzZXIgaW4gdGhpcyBkcmFmdCwgYnV0IGVpdGhlciB0byBhIFJRIG9yIGFuIFJPLg0K W0ZJXSB5ZXMgdGhhdCB3b3VsZCBhdm9pZCBwb3RlbnRpYWwgbWlzdW5kZXJzdGFuZGluZ3MuIEFs dGhvdWdoIGluIHRoZSBlbmQsIHBlb3BsZSB3aWxsIHRyYW5zbGF0ZSBSUSBpbnRvIHVzZXIgb3Ig ZW5kLXVzZXIgbW9zdCBvZiB0aGUgdGltZS4gQ2YgaW4gZGVmaW5pdGlvbiwgY3VycmVudGx5IHdl IGhhdmUgUmVxdWVzdGluZyBQYXJ0eSAoUlEsIGFrYSAidXNlciIpDQoNCg0KSW50ZXJhY3Rpb24g QWdhaW4NCi0+IEZvciBlYWNoIGludGVyYWN0aW9uIHR5cGUsIHdlIHdpbGwgaGF2ZSB0byBkZXNj cmliZSB0aGUgcHJvdG9jb2wgZmxvdyBhbmQgdGhlIG5hdHVyZSBhbmQgYmVoYXZpb3Igb2YgaW52 b2x2ZWQgUm9sZXMgKFBhcnRpZXMpLCBFbGVtZW50cywgUmVxdWVzdHMuDQpbRkldIHllcw0KDQpb RlBdIFdpbGwgdGhlc2UgYW5kIGludG8gdGlja2V0cz8NCg0KQmVzdCByZWdhcmRzLg0KL0ZyYW5j aXMNCg0KDQoNCg0KDQotLQ0KVFhBdXRoIG1haWxpbmcgbGlzdA0KVFhBdXRoQGlldGYub3JnPG1h aWx0bzpUWEF1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3R4YXV0aA0KLS0NClRYQXV0aCBtYWlsaW5nIGxpc3QNClRYQXV0aEBpZXRmLm9yZzxtYWls dG86VFhBdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90eGF1dGgNCg0KLS0NClRYQXV0aCBtYWlsaW5nIGxpc3QNClRYQXV0aEBpZXRmLm9yZzxtYWls dG86VFhBdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90eGF1dGgNCi0tDQpUWEF1dGggbWFpbGluZyBsaXN0DQpUWEF1dGhAaWV0Zi5vcmc8bWFpbHRv OlRYQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dHhhdXRoDQoNCi0tDQpUWEF1dGggbWFpbGluZyBsaXN0DQpUWEF1dGhAaWV0Zi5vcmc8bWFpbHRv OlRYQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dHhhdXRoDQoNCg0KLS0NClRYQXV0aCBtYWlsaW5nIGxpc3QNClRYQXV0aEBpZXRmLm9yZzxtYWls dG86VFhBdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90eGF1dGgNCg0KLS0NClRYQXV0aCBtYWlsaW5nIGxpc3QNClRYQXV0aEBpZXRmLm9yZzxtYWls dG86VFhBdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90eGF1dGgNCg== --_000_FR2P281MB0106C0A62253D04A1070873F8DB09FR2P281MB0106DEUP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNv bG9yOiByZ2IoMCwgMCwgMCk7Ij4NCkhlbGxvIEZhYmlhbiw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KSSBhbSBzb3JyeSBmb3IgdGhl IGRlbGF5ZWQgcmVwbHksIGJ1dCB2ZXJ5IGJ1c3kgd29ya2luZyBvbiB0aG9zZSBkZWNlbnRyYWxp emVkIHVzZSBjYXNlcyB3aGVyZSB0b2tlbnMgYSBwcm9kdWNlZCBvbiB0aGUgdXNlciBkZXZpY2Uu PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8 YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7 Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFs LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAw LCAwKTsiPg0KTGlrZSB3ZSBjYW4gc2VlIGluIHRoaXMgdGhyZWFkLCBpdCBpcyBub3Qgb2J2aW91 cyB0byBoYXZlIHRob3NlIHVzZSBjYXNlcyBjb25zaWRlcmVkIGluIEdOQVAgKGFzIHRoZSBHTkFQ IGNoYXJ0ZXIgbWVudGlvbnMgcmVsaWFuY2Ugb24gSFRUUCBiYXNlZCBBUykuPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCklmIHRoZSBy b2xlIG9mIGFuIEFTIGlzIHRvIHByb2R1Y2UgYW4gYXV0aG9yaXphdGlvbiwgYSB1c2VyIGRldmlj ZSBob3N0ZWQgQVMgY2FuIGJlIGJ1aWxkLCBidXQgdGhlIG5lZ290aWF0aW9uIHByb2Nlc3Mgd2ls bCBiZSBkaWZmZXJlbnQgZnJvbSB0aGUgb25lIGRlZmluZWQgYnkgR05BUC4gTWVhbnMgaW50ZXJh Y3Rpb24gcHJvdG9jb2wgd2lsbCBuZWVkIG1vcmUgdGhhbiBqdXN0IEhUVFAuPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NClRoZSBiaWdn ZXN0IGNoYWxsZW5nZSB3ZSBhcmUgZmFjaW5nIG9uIHVzZXIgZGV2aWNlIHByb2R1Y2VkIGF1dGgg dG9rZW5zIGlzIG9uIGhvdyB0byBwcmVzZXJ2ZSB0aG9zZSBjcnlwdG8ga2V5cyBoZWxkIG9uIHVz ZXIgZGV2aWNlIGZyb20gbWFsd2FyZSwgbG9zcyBvZiBkZXZpY2UuLi48L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KRm9yIHRoZSBtb21l bnQga2VlcGluZyBmb2N1cyBvZiBHTkFQIG9uIChodHRwKSBzZXJ2ZXItYmFzZWQgcHJvZHVjdGlv biBvZiB0b2tlbiBsb29rcyBsaWtlIGEgZ29vZCBkZWNpc2lvbi48L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KSSB3aWxsIHJldmlldyB0 aGUgZHJhZnQgc29tZXRpbWUgYXMgc29vbiBhcyBwb3NzaWJsZSBhbmQgcHJvdmlkZSBteSBmZWVk YmFjay48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7 Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFs LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAw LCAwKTsiPg0KQmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENh bGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29s b3I6IHJnYigwLCAwLCAwKTsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0 OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQovRnJhbmNpczwvZGl2Pg0KPGRpdiBpZD0iYXBwZW5k b25zZW5kIj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVs dmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMnB0OyBjb2xvcjpyZ2IoMCwwLDApIj4NCjxi cj4NCjwvZGl2Pg0KPGhyIHRhYmluZGV4PSItMSIgc3R5bGU9ImRpc3BsYXk6aW5saW5lLWJsb2Nr OyB3aWR0aDo5OCUiPg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyIgZGlyPSJsdHIiPjxmb250IGZh Y2U9IkNhbGlicmksIHNhbnMtc2VyaWYiIGNvbG9yPSIjMDAwMDAwIiBzdHlsZT0iZm9udC1zaXpl OjExcHQiPjxiPkZyb206PC9iPiBUWEF1dGggJmx0O3R4YXV0aC1ib3VuY2VzQGlldGYub3JnJmd0 OyBvbiBiZWhhbGYgb2YgRmFiaWVuIEltYmF1bHQgJmx0O2ZhYmllbi5pbWJhdWx0QGdtYWlsLmNv bSZndDs8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSA1LCAyMDIxIDM6NDEgUE08 YnI+DQo8Yj5Ubzo8L2I+IEFkcmlhbiBHcm9wcGVyICZsdDthZ3JvcHBlckBoZWFsdGh1cmwuY29t Jmd0Ozxicj4NCjxiPkNjOjwvYj4gVG9tIEpvbmVzICZsdDt0aG9tYXNjbGluZ2Fuam9uZXNAZ21h aWwuY29tJmd0OzsgdHhhdXRoIGduYXAgJmx0O3R4YXV0aEBpZXRmLm9yZyZndDs7IEp1c3RpbiBS aWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtH TkFQXSBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1nbmFwLWNvcmUtcHJvdG9jb2wtMDA8L2ZvbnQ+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPkhpIEFkcmlh biwNCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5XZSB3b3Vs ZCBiZSBnbGFkIHRvIGdldCB5b3VyIGV4cGVydGlzZSBvbiB0aGF0LiBOb3Qgc3VyZSBESURDb21t IGlzIGVzc2VudGlhbCB5ZXQsIHNvIGZhciBJIHNlZSBpdCBwZXJzb25hbGx5IGFzIHNvbWV0aGlu ZyB0byBsb29rIGludG8sIGVzcGVjaWFsbHkgZm9yIHVzZSBjYXNlcyB3aGVuIHdlIHdhbnQgdG8g cmVhY2ggb3V0IHRvIGEgUk8uIEkgYWdyZWUgd2l0aCB0aGUgcG90ZW50aWFsIGlzc3Vlcy4mbmJz cDs8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5J IGhhdmUgYSBmZXcgaWRlYXMgb24gaG93IHRvIGltcGxlbWVudCBwcml2YWN5LCBidXQgaXQncyBx dWl0ZSBpbnZvbHZlZCBpbiB0ZXJtcyBvZiBjcnlwdG8gKGFnYWluIHVzaW5nIFJpc3RyZXR0byBn cm91cHMgOi0pKS48L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGly PSJhdXRvIj5PZiBjb3Vyc2UgdGhlcmUgd2lsbCBiZSBhIHF1ZXN0aW9uIG9mIHByaW9yaXR5IGlu IHRoZSBmZWF0dXJlcyB3ZSBwbGFuIHRvIGltcGxlbWVudC4gSSBndWVzcyB3ZSBzaG91bGQgYWlt IGZvciBhIGZpcnN0IHB1YmxpY2F0aW9uIHdpdGhvdXQgdGhlIHBhcnRzIHdoaWNoIGFyZSBibHVy cnksIGFuZCB0YWtlIHRoZSB0aW1lIHRvIHByb3RvdHlwZSB0aGUgcmVzdC4mbmJzcDs8L2Rpdj4N CjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5DaGVlcnM8L2Rp dj4NCjxkaXYgZGlyPSJhdXRvIj5GYWJpZW4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGRp diBjbGFzcz0ieF9nbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0ieF9nbWFpbF9h dHRyIj5MZSB2ZW4uIDUgZsOpdnIuIDIwMjEgw6AgMjE6MTksIEFkcmlhbiBHcm9wcGVyICZsdDs8 YSBocmVmPSJtYWlsdG86YWdyb3BwZXJAaGVhbHRodXJsLmNvbSI+YWdyb3BwZXJAaGVhbHRodXJs LmNvbTwvYT4mZ3Q7IGEgw6ljcml0Jm5ic3A7Ojxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xh c3M9InhfZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDsgYm9yZGVyLWxlZnQ6 MXB4ICNjY2Mgc29saWQ7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+VGhlcmUg YXJlIHByaXZhY3kgaW1wbGljYXRpb25zIGFzIHdlbGwgYXMgdGhlIGNvc3Qgb2YgcHJvY2Vzc2lu ZyBzcGFtLiBBIHNlcnZpY2UgZW5kcG9pbnQgYXNzb2NpYXRlZCB3aXRoIGEgRElEIGNhbiBiZSBw cmVzdW1lZCB0byBiZSBhIHB1YmxpYyBicm9hZGNhc3QuIEFueSBwYXJ0eSBjYW4gYXR0ZW1wdCB0 byBzZW5kIGEgbWVzc2FnZSBvciBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3QgdG8gdGhhdCBzZXJ2 aWNlIGVuZHBvaW50Lg0KIFRoZSBvcGVyYXRvciBvZiB0aGF0IHNlcnZpY2UsIHR5cGljYWxseSB0 aGUgRElEIGNvbnRyb2xsZXIsIHdpbGwgYmVhciB0aGUgY29zdCBhbmQgcmlzayBvZiBwcm9jZXNz aW5nIHRoZSBtZXNzYWdlLiBUaGV5IG1heSByZXF1ZXN0IGEgYm9uZCBiZSBwb3N0ZWQgYnkgdGhl IHBhcnR5IHJlc3BvbmRpbmcgdG8gdGhlICZxdW90O2Jyb2FkY2FzdCZxdW90OyBpbiBvcmRlciB0 byBtaXRpZ2F0ZSBzcGFtIGFuZCBwaGlzaGluZy4gVGhleSBtYXkgYWxzbyByZXF1aXJlIHRoYXQN CiB0aGUgcGFydHkgc2Vla2luZyB0byBjb21tdW5pY2F0ZSBvZmZlciBjcmVkZW50aWFscywgd2hp Y2ggcG9zZXMgYSBwcml2YWN5IHJpc2sgdG8gdGhhdCBwYXJ0eSBpbiB0aGUgZm9ybSBvZiBwaGlz aGluZyAmcXVvdDticm9hZGNhc3RzJnF1b3Q7IHZpYSBESURzIGFuZCBsdXJlcyB0aGF0IGxlYWQg dG8gRElEcy4mbmJzcDsNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkluIG15IHJvbGUgYXMgaW52 aXRlZCBleHBlcnQgb24gcHJpdmFjeSB0byBzb21lIFczQyBXR3MgYW5kLCB0byBzb21lIGV4dGVu dCwgRElGIFdHcywgSSBoYXZlIG5vdCBtYW5hZ2VkIHRvIHVuZGVyc3RhbmQgdGhlIHByaXZhY3kg ZW5naW5lZXJpbmcgYW5kIGltcGxpY2F0aW9ucyBpbiBESURjb21tLiBJIHdpbGwgdHJ5IGhhcmRl ciBpZiBESURjb21tIGhhcyBhbiBlc3NlbnRpYWwgcm9sZSB3aXRoIEdOQVAgYW5kIEkgY2FuIHVu ZGVyc3RhbmQNCiBpdCBpbiB0aGUgc2VsZi1zb3ZlcmVpZ24gb3IgZmlkdWNpYXJ5IGF1dGhvcml6 YXRpb24gc2VydmVyIGNvbnRleHQuIERvZXMgaXQ/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5BZHJpYW48L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGRpdiBjbGFzcz0ieF9nbWFpbF9xdW90 ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0ieF9nbWFpbF9hdHRyIj5PbiBGcmksIEZlYiA1LCAy MDIxIGF0IDE6MDggUE0gRmFiaWVuIEltYmF1bHQgJmx0OzxhIGhyZWY9Im1haWx0bzpmYWJpZW4u aW1iYXVsdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIiPmZhYmll bi5pbWJhdWx0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgY2xhc3M9InhfZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7 IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IGJvcmRlci1s ZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9 Imx0ciI+UHJvYmFibHkgKGFuZCB0byBiZSBob25lc3QgZXZlbiBmb3IgaW5kdXN0cmlhbCB1c2Vy cyBJIGZpbmQgaXQgY29tcGxleCksIGJ1dCBhbHRlcm5hdGl2ZXMgYXJlIG5vdCByZWFkeSBmb3Ig cHJpbWUgdGltZSBlaXRoZXIuJm5ic3A7DQo8ZGl2Pk1heWJlIHNvbWUgZGF5Jm5ic3A7RElEQ29t bSBjb3VsZCBiZSB1c2VmdWwgYXMgYSBiYXNpYyBibG9jaywgd2hhdCB3ZSBzdWdnZXN0IGlzIHRv IGZpcnN0IHVzZSB0aGF0IGFzIGEgcG90ZW50aWFsIGludGVyYWN0aW9uIChhbmQgdGhlcmUncyBh bHJlYWR5IGEgbG90IG9mIHF1ZXN0aW9ucyB0aGF0IGFyaXNlIGp1c3QgZnJvbSB0aGF0KS4mbmJz cDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkZhYmllbjwvZGl2Pg0KPC9kaXY+DQo8 YnI+DQo8ZGl2IGNsYXNzPSJ4X2dtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJ4 X2dtYWlsX2F0dHIiPk9uIEZyaSwgRmViIDUsIDIwMjEgYXQgNjo1NSBQTSBUb20gSm9uZXMgJmx0 OzxhIGhyZWY9Im1haWx0bzp0aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayIgcmVsPSJub3JlZmVycmVyIj50aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0ieF9nbWFpbF9xdW90ZSIg c3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6MXB4OyBi b3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0 KTsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0iYXV0byI+Tm8sIHlvdSBkaWRuJ3QgbWlz dW5kZXJzdGFuZCBtZS4gSXQncyBqdXN0IHRoYXQgdGhlIHV4IGZvciB0aGF0IGlzIG5vdCBhY2Nl cHRhYmxlIHRvIHJldGFpbCB1c2Vycy4gQXMgbG9uZyBhcyBnbmFwIHN0aWNrcyB0byBpbmR1c3Ry aWFsIHVzZXJzIHlvdSBzaG91bGQgZG8gZmluZS48YnI+DQo8YnI+DQo8ZGl2PnRoeCAuLlRvbSAo bW9iaWxlKTwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJ4X2dtYWlsX3F1b3RlIj4N CjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJ4X2dtYWlsX2F0dHIiPk9uIEZyaSwgRmViIDUsIDIwMjEs IDc6NTYgQU0gRmFiaWVuIEltYmF1bHQgJmx0OzxhIGhyZWY9Im1haWx0bzpmYWJpZW4uaW1iYXVs dEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIiPmZhYmllbi5pbWJh dWx0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xh c3M9InhfZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJvcmRl ci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IGJvcmRlci1sZWZ0LWNv bG9yOnJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+ DQo8ZGl2IGRpcj0iYXV0byI+DQo8ZGl2PlRhcmdldGluZyBleGlzdGluZyBicm93c2VycyBhbmQg dHlwZXMgb2YgYXBwbGljYXRpb25zICh3ZWIsIHB3YSwgbW9iaWxlLCBldGMuKSBzZWVtcyBsaWtl IGEgcmVhc29uYWJsZSBvcHRpb24gZm9yIGFuIGluZHVzdHJpYWwgc3RhbmRhcmQuIEltcHJvdmlu ZyBzZWN1cml0eSwgcHJpdmFjeSwgZWFzZSBvZiB1c2UgYW5kIGludGVyb3BlcmFiaWxpdHkgKGlu Y2x1ZGluZyBkZWNlbnRyYWxpemVkIGlkZW50aXR5IGFzIHdlbGwpIHNob3VsZCBiZQ0KIGdvb2Qg ZW5vdWdoIG9iamVjdGl2ZXMuJm5ic3A7PC9kaXY+DQo8ZGl2PlBsdXMgZnJvbSBvdXIgcHJldmlv dXMgZGlzY3Vzc2lvbnMsIEkgd2FzIHVuZGVyIHRoZSBpbXByZXNzaW9uIHlvdSB3ZXJlIGZpbmUg d2l0aCB0aGUgYXBwcm9hY2ggb2YgZGVwbG95aW5nIHRoZSBBUyBvbiB0aGUgcGhvbmUgYXMgYSBs b29wYmFjaywgZm9yIG1vYmlsZSBhcHBzLiBEaWQgSSBtaXNzIHNvbWV0aGluZz88L2Rpdj4NCjxk aXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2hlZXJzLDwvZGl2Pg0KPGRpdiBkaXI9 ImF1dG8iPkZhYmllbjxicj4NCjxicj4NCjxkaXYgY2xhc3M9InhfZ21haWxfcXVvdGUiIGRpcj0i YXV0byI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0ieF9nbWFpbF9hdHRyIj5MZSB2ZW4uIDUgZsOp dnIuIDIwMjEgw6AgMTY6MzMsIFRvbSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRob21hc2Ns aW5nYW5qb25lc0BnbWFpbC5jb20iIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9 Il9ibGFuayI+dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbTwvYT4mZ3Q7IGEgw6ljcml0Jm5i c3A7Ojxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9InhfZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVy LWxlZnQtc3R5bGU6c29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IHBh ZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2PklmIHlvdSBtZWFuIGNhbiBH TkFQIHdvcmsgb24gb2xkIGZhc2hpb25lZCBhcHBzIHJ1bm5pbmcgd2l0aCBleGlzdGluZyBicm93 c2VycyBhbmQgZXhpc3RpbmcgaWRlbnRpdHkgcHJvdmlkZXJzLCB0aGVuIHllcywgaSBndWVzcyB5 b3UgYXJlIG9rLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SWYgeW91IHdhbnQgdG8g d29yayBvbiBhcHBzIHdoZXJlIHRoZSB1c2VyIGlzIGluIGNvbnRyb2wgb2YgYXV0aG4gYW5kIGF1 dGh6LCB0aGVuIG5vLCBHTkFQIGNhbm5vdCB3b3JrLiBJdCBpcyBub3QgYWxvbmUgaW4gdGhhdCBP SURDIHdvbnQgd29yayB0aGVyZSBlaXRoZXIuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj48c3BhbiBz dHlsZT0iYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjQyLDI0MiwyNDIpOyBjb2xvcjpyZ2JhKDAsMCww LDAuOSk7IGZvbnQtc2l6ZToxNHB4OyB3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+QmUgdGhlIGNoYW5n ZSB5b3Ugd2FudCB0byBzZWUgaW4gdGhlIHdvcmxkDQo8L3NwYW4+Li50b208L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8ZGl2IGNsYXNz PSJ4X2dtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJ4X2dtYWlsX2F0dHIiPk9u IEZyaSwgRmViIDUsIDIwMjEgYXQgMzoxOSBBTSBGYWJpZW4gSW1iYXVsdCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbSIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9InhfZ21haWxfcXVv dGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOjFw eDsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0 LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0iYXV0 byI+DQo8ZGl2IGRpcj0iYXV0byI+SGkgVG9tLCZuYnNwOzwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8i Pjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPlRoYW5rcywgeW91ciByZXNwb25zZXMgbWFk ZSBpdCBjbGVhcmVyIGZvciBtZSB3aGF0IHlvdSBleHBlY3QgZnJvbSBhbiBBUyBkZXBsb3llZCBv biBhIG1vYmlsZS4mbmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxk aXYgZGlyPSJhdXRvIj5JIHRoaW5rIHdlJ3JlIG9uIHRoZSByaWdodCBwYXRoIHRvIG1lZXQgdGhl IHJlc3Qgb2YgeW91ciBjb25jZXJucy4gVGhlcmUgYXJlIGFscmVhZHkgYSBmZXcgaXRlbXMgb24g dGhlc2U6PC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+LSBwcml2YWN5IHByZXNlcnZpbmcgdGVjaG5p cXVlcyBoYXZlIGJlZW4gZGlzY3Vzc2VkIGFuZCBhcmUgbGlrZWx5IHRvIGJlIGluY2x1ZGVkIChJ IHRoaW5rKS4gSXQncyBiZWVuIHJlY29nbml6ZWQgYXMgYSBjb3JlIGNvbmNlcm4mbmJzcDs8L2Rp dj4NCjxkaXYgZGlyPSJhdXRvIj4tIG5vdCBleGFjdGx5IHN1cmUgdGhlIG1lYW5pbmcgeW91IGdp dmUgdG8gZGlzY292ZXJ5IGhlcmUgKGl0J3MgYWxyZWFkeSBiZWVuIHVzZWQgaW4gdGhlIFdHIGJ1 dCB3aXRoIGEgZGlmZmVyZW50IG1lYW5pbmcgSSBiZWxpZXZlKS4gVGhlIHJlcXVlc3Qgb3IgdGhl IGNvbnRpbnVhdGlvbiBhcGkgcHJvdmlkZSBlbnRyeSBwb2ludHMgdG8gcGF5IGF0dGVudGlvbiB0 by4mbmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXY+SXMgdGhh dCBlbm91Z2ggZm9yIHlvdXIgdXNlIGNhc2UgPyBEbyB5b3UgbmVlZCBzb21ldGhpbmcgZWxzZSA/ IChsaWtlIFNTRT8pPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRp cj0iYXV0byI+Q2hlZXJzPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+RmFiaWVuJm5ic3A7PC9kaXY+ DQo8YnI+DQo8ZGl2IGNsYXNzPSJ4X2dtYWlsX3F1b3RlIiBkaXI9ImF1dG8iPg0KPGRpdiBkaXI9 Imx0ciIgY2xhc3M9InhfZ21haWxfYXR0ciI+TGUgamV1LiA0IGbDqXZyLiAyMDIxIMOgIDIyOjEw LCBUb20gSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwu Y29tIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9y ZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJn ZXQ9Il9ibGFuayI+dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbTwvYT4mZ3Q7DQogYSDDqWNy aXQmbmJzcDs6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0ieF9nbWFpbF9xdW90ZSIg c3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6MXB4OyBi b3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0 KTsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIj5kaXNjb3ZlcnkgaXMgdGhlIHBy aW1lIHByb2JsZW0uJm5ic3A7IFdoYXQgY2F1c2VzIHRoZSB3YWxsZXQvQVMgdG8gd2FrZSB1cCBh bmQgcGF5IGF0dGVudGlvbi4gSG93IGRvZXMgdGhlIFJQIGtub3cgd2hhdCB0byBhc2sgZm9yIHdp dGhvdXQgdmlvbGF0aW5nIHVzZXIgcHJpdmFjeSByaWdodHM/DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5DSEFQSSB3b3VsZCBiZSBvayBpIGd1ZXNzLCBidXQgdGhhdCByZXF1aXJlcyBjcmVkIG1h biB0byBiZSBmaXhlZC4gTm90IHN1cmUgaWYgaXQgZml4ZXMgZGlzY292ZXJ5IG9yIHByaXZhY3kg ZXZlbiB0aGVuLjxicj4NCjxkaXY+PGJyIGNsZWFyPSJhbGwiPg0KPGRpdj4NCjxkaXYgZGlyPSJs dHIiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9y OnJnYigyNDIsMjQyLDI0Mik7IGNvbG9yOnJnYmEoMCwwLDAsMC45KTsgZm9udC1zaXplOjE0cHg7 IHdoaXRlLXNwYWNlOnByZS13cmFwIj5CZSB0aGUgY2hhbmdlIHlvdSB3YW50IHRvIHNlZSBpbiB0 aGUgd29ybGQNCjwvc3Bhbj4uLnRvbTwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGRpdiBjbGFzcz0ieF9nbWFpbF9xdW90 ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0ieF9nbWFpbF9hdHRyIj5PbiBUaHUsIEZlYiA0LCAy MDIxIGF0IDEyOjQ1IFBNIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVy QG1pdC5lZHUiIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7DQogd3Jv dGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0ieF9nbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6MXB4OyBib3JkZXIt bGVmdC1zdHlsZTpzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTsgcGFk ZGluZy1sZWZ0OjFleCI+DQo8ZGl2PlRvbSwgd2hhdCBhZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdHkg ZG8geW91IHNlZSB0aGF0IGEgYnJvd3NlciB3b3VsZCBuZWVkIHRvIHN1cHBvcnQgaW4gb3JkZXIg Zm9yIEdOQVAgdG8gYmUgYWRvcHRlZD8gRm9yIHRoZSBlbGVtZW50cyBvZiB0aGUgY29yZSBwcm90 b2NvbCB0b2RheSwgbm90aGluZyBpcyBuZWVkZWQgdG8gY2hhbmdlIHdpdGhpbiB0aGUgYnJvd3Nl cnMg4oCUIGV2ZXJ5dGhpbmcgaXMgYnVpbHQgb24gZXhpc3RpbmcgZnVuY3Rpb25zLg0KIEdOQVAg dXNlcyBicm93c2VycyBhcyBhIHRvb2wsIGFuZCBJIHdvdWxkIGFyZ3VlIGRlcGVuZHMgb24gdGhl bSBldmVuIGxlc3Mgc28gdGhhbiBPQXV0aCAyIGRvZXMuIEV4dGVuc2lvbnMgY291bGQgdXNlIGJy b3dzZXIgZnVuY3Rpb25hbGl0eSwgbGlrZSB1c2luZyBDSEFQSSB0byBwYXNzIGludGVyYWN0aW9u IGVsZW1lbnRzLCBidXQgdGhlIGNvcmUgcHJvdG9jb2wgZnVuY3Rpb25zIG9uIHZhbmlsbGEgYnJv d3NlcnMgdG9kYXkuDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDvigJQgSnVzdGluPGJy Pg0KPGRpdj48YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+T24gRmViIDQsIDIw MjEsIGF0IDM6MjAgUE0sIFRvbSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRob21hc2NsaW5n YW5qb25lc0BnbWFpbC5jb20iIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPnRob21hc2NsaW5nYW5qb25lc0Bn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxicj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRy Ij5pIGFzc3VtZWQgdGhhdCB0aGUgd2FsbGV0IChha2EgQVMpIG5lZWRlZCB0byBiZSBhIG5hdGl2 ZSBhcHAsIG5vdCBhIFBXQSAod2hpY2ggY2FuIGNvbWUgZnJvbSBhIHRyYWRpdGlvbmFsIHdlYiBz ZXJ2ZXIpLg0KPGRpdj5UaGVyZSBhcmUgZm9sa3MsIGxrZSBLaW0gQywgd2hvIGFyZSB3b3JraW5n IG9uIGEgUFdBLCBidXQgaSBhZ3JlZSB0aGUgYmxvY2tzIHRoZXJlIHNlZW0gdG8gYmUgbGFyZ2Uu PC9kaXY+DQo8ZGl2PlRIZSBibG9ja3Mgb24gYSBuYXRpdmUgYXBwIGFyZSBzaW1wbGUsIGVhc3kg dG8gZGVzY3JpYmUsIGFuZCBlYXN5IHRvIGFzayB0aGUgYnJvd3NlciBndXlzIHRvIGZpeC4gTm90 IHN1cmUgaWYgdGhleSBjYXJlIHRoby48L2Rpdj4NCjxkaXY+SSBoYXZlIHRyb3VibGUgc2VlaW5n IGEgcGF0aCB0byBHTkFQIGFkb3B0aW9uIGZvciByZXRhaWwgY3VzdG9tZXJzIHcvbyBzb21lIGJy b3dzZXIgc3VwcG9ydC48L2Rpdj4NCjxkaXY+VGhhdCdzIHdoeSBpIGFtIG1vc3RseSZuYnNwO3Np bGVudCBoZXJlLjwvZGl2Pg0KPGRpdj48YnIgY2xlYXI9ImFsbCI+DQo8ZGl2Pg0KPGRpdiBkaXI9 Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29s b3I6cmdiKDI0MiwyNDIsMjQyKTsgZm9udC1zaXplOjE0cHg7IHdoaXRlLXNwYWNlOnByZS13cmFw Ij5CZSB0aGUgY2hhbmdlIHlvdSB3YW50IHRvIHNlZSBpbiB0aGUgd29ybGQNCjwvc3Bhbj4uLnRv bTwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxi cj4NCjxkaXYgY2xhc3M9InhfZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9Inhf Z21haWxfYXR0ciI+T24gVGh1LCBGZWIgNCwgMjAyMSBhdCAxMTo0MyBBTSBGYWJpZW4gSW1iYXVs dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbSIgcmVsPSJub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZl cnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9 Il9ibGFuayI+ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPC9hPiZndDsNCiB3cm90ZTo8YnI+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJ4X2dtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBw eCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDoxcHg7IGJvcmRlci1sZWZ0LXN0eWxl OnNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpOyBwYWRkaW5nLWxlZnQ6 MWV4Ij4NCjxkaXYgZGlyPSJhdXRvIj5GYWlyIGVub3VnaC4gQnV0IGxvb3BiYWNrIGxpbWl0cyBh IGxvdCB3aGF0IHlvdSBjYW4gZG8uLi4gSnVzdCBmb3IgZGVidWcgaXQncyBhIHBhaW4uJm5ic3A7 DQo8ZGl2IGRpcj0iYXV0byI+QnV0IGFzIHNvb24gYXMgeW91IHRyeSBtb3JlLCBpdCdzIGEgYml0 IGNyYXp5LiBGdW4gdG8gdGVzdCBpcHY2IChsdWNraWx5IHN1cHBvcnRlZCBieSBteSBJU1ApIGFu ZCBkZG5zLiBCdXQgaXQgZmVlbHMgcmVhbGx5IGhhY2t5LiZuYnNwOzwvZGl2Pg0KPGRpdiBkaXI9 ImF1dG8iPkFsc28gZGVwbG95bWVudCBpcyBhIHBhaW4sIGNvbXBhcmVkIHRvIGEgdHJhZGl0aW9u YWwgd2Vic2VydmVyLiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJ4X2dt YWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJ4X2dtYWlsX2F0dHIiPkxlIGpldS4g NCBmw6l2ci4gMjAyMSDDoCAyMDoyMCwgVG9tIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86dGhv bWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbSIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9y ZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVm ZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVy cmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj50aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwu Y29tPC9hPiZndDsNCiBhIMOpY3JpdCZuYnNwOzo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNs YXNzPSJ4X2dtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3Jk ZXItbGVmdC13aWR0aDoxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBib3JkZXItbGVmdC1j b2xvcjpyZ2IoMjA0LDIwNCwyMDQpOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIi PmRvZXNuJ3Qgd29yayB2ZXJ5IHdlbGwgb24gd2luZG93cyB1d3AuIHdvcmtzIGZpbmUgb24gc21h cnRwaG9uZXM8YnIgY2xlYXI9ImFsbCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0K PGRpdiBkaXI9Imx0ciI+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYigy NDIsMjQyLDI0Mik7IGZvbnQtc2l6ZToxNHB4OyB3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+QmUgdGhl IGNoYW5nZSB5b3Ugd2FudCB0byBzZWUgaW4gdGhlIHdvcmxkDQo8L3NwYW4+Li50b208L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8ZGl2 IGNsYXNzPSJ4X2dtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJ4X2dtYWlsX2F0 dHIiPk9uIFRodSwgRmViIDQsIDIwMjEgYXQgMTE6MTggQU0gSnVzdGluIFJpY2hlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0 LmVkdTwvYT4mZ3Q7DQogd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0ieF9n bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQt d2lkdGg6MXB4OyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6cmdi KDIwNCwyMDQsMjA0KTsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2Pk9LLCB0aGFua3Mg4oCUIGlu IHRoYXQgY2FzZSwgdGhlcmUgYXJlIG5vIGNoYW5nZXMgYXQgYWxsIHRvIEdOQVAsIHdoaWNoIGlz IGFscmVhZHkgSFRUUCBkcml2ZW4uIFRoZSBoYXJkZXIgcGFydHMgdGVuZCB0byBiZSB3aGVyZSB5 b3UgY2Fu4oCZdCAob3IgZG9u4oCZdCB3YW50IHRvKSB1c2Ugc29tZXRoaW5nIGxpa2UgdGhhdC4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiZuYnNwO+KAlCBKdXN0aW48YnI+DQo8ZGl2Pjxicj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj5PbiBGZWIgNCwgMjAyMSwgYXQgMjoxNiBQ TSwgVG9tIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWls LmNvbSIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiPnRob21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb208L2E+Jmd0 Ow0KIHdyb3RlOjwvZGl2Pg0KPGJyPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj55ZXMs IGxvb3BiYWNrPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRp cj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1j b2xvcjpyZ2IoMjQyLDI0MiwyNDIpOyBmb250LXNpemU6MTRweDsgd2hpdGUtc3BhY2U6cHJlLXdy YXAiPkJlIHRoZSBjaGFuZ2UgeW91IHdhbnQgdG8gc2VlIGluIHRoZSB3b3JsZA0KPC9zcGFuPi4u dG9tPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0K PGJyPg0KPGRpdiBjbGFzcz0ieF9nbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0i eF9nbWFpbF9hdHRyIj5PbiBUaHUsIEZlYiA0LCAyMDIxIGF0IDExOjAxIEFNIEp1c3RpbiBSaWNo ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHJlbD0ibm9yZWZlcnJlciBu b3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9y ZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVm ZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5q cmljaGVyQG1pdC5lZHU8L2E+Jmd0Ow0KIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg Y2xhc3M9InhfZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJv cmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IGJvcmRlci1sZWZ0 LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdj5Ub20sIGNh biB5b3UgZXhwYW5kIG9uIGhvdyBleGFjdGx5IHRoZSBiYWNrLWNoYW5uZWwgJm5ic3A7Y29tbXVu aWNhdGlvbiB3b3JrcyBiZXR3ZWVuIG9uLWRldmljZSBjb21wb25lbnRzPyBEbyB5b3UgdXNlIEhU VFAgbG9jYWxseT8NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+ Jm5ic3A74oCUIEp1c3Rpbjxicj4NCjxkaXY+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ DQo8ZGl2Pk9uIEZlYiA0LCAyMDIxLCBhdCAxOjAzIFBNLCBUb20gSm9uZXMgJmx0OzxhIGhyZWY9 Im1haWx0bzp0aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tIiByZWw9Im5vcmVmZXJyZXIgbm9y ZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVm ZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVy cmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+dGhv bWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbTwvYT4mZ3Q7DQogd3JvdGU6PC9kaXY+DQo8YnI+DQo8 ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+SnVzdGluJ3MgYW5hbHlzaXMgb2YgdXNlIG9mIHRoZSBmcm9u dCBjaGFubmVsIGlzIG1pc2xlYWRpbmcuDQo8ZGl2Pkl0IGNvdWxkIGVxdWFsbHkgYmUgYXJndWVk IHRoYXQgd2hhdCBpIGhhdmUgZG9uZSBpcyBpbnN0YWxsZWQgYW4gQVMgb24gdGhlIHBob25lIGFu ZCB0aGUgY29tbXVuaWNhdGlvbnMgd2l0aCBpdCAmYW1wOyB0aGUgUFIgaXMgYmFjayBjaGFubmVs LjwvZGl2Pg0KPGRpdj5CYXNpY2FsbHkgdGhlIHBvaW50IGlzIHRoYXQgdGhlIG9sZCBPSURDIHBh cmFkaWdtcyBhcmUgbm8gbG9uZ2VyIHZhbGlkLjxiciBjbGVhcj0iYWxsIj4NCjxkaXY+DQo8ZGl2 IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZC1jb2xvcjpyZ2IoMjQyLDI0MiwyNDIpOyBmb250LXNpemU6MTRweDsgd2hpdGUtc3BhY2U6cHJl LXdyYXAiPkJlIHRoZSBjaGFuZ2UgeW91IHdhbnQgdG8gc2VlIGluIHRoZSB3b3JsZA0KPC9zcGFu Pi4udG9tPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGJyPg0KPGRpdiBjbGFzcz0ieF9nbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFz cz0ieF9nbWFpbF9hdHRyIj5PbiBUaHUsIEZlYiA0LCAyMDIxIGF0IDc6NDcgQU0gRmFiaWVuIElt YmF1bHQgJmx0OzxhIGhyZWY9Im1haWx0bzpmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb20iIHJlbD0i bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdl dD0iX2JsYW5rIj5mYWJpZW4uaW1iYXVsdEBnbWFpbC5jb208L2E+Jmd0Ow0KIHdyb3RlOjxicj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9InhfZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46 MHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtc3R5 bGU6c29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVm dDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+WWVzLCBpc3N1ZSAoIzE2OCkmbmJzcDttZXNzYWdlIGJh c2VkIGludGVyYWN0aW9uIC8gRElEQ29tbSBpcyBhIHRlbnRhdGl2ZSBhbHRlcm5hdGl2ZSBtZWNh bmlzbSBmb3IgdGhlIGludGVyYWN0aW9uIHBhcnQuIE5vdCBzdXJlIGhvdyB0aGF0IHdvdWxkIHdv cmsgaW4gZGV0YWlscyZuYnNwO3Rob3VnaCwgcHJvdG90eXBpbmcgd2lsbCBwcm9iYWJseSBoZWxw IGhlcmUuDQo8ZGl2PlRva2VuIGRlbGl2ZXJ5Jm5ic3A7dGhyb3VnaCBjb250aW51YXRpb24gc2Vl bXMgZmluZSB0byBtZS4gVGhlIGNsaWVudCB3aWxsIHByb2JhYmx5IGhhdmUgdG8gd2FpdCBmb3Ig dGhlIG5leHQgcG9sbGluZyBiZWZvcmUgaXQgcmVjZWl2ZXMgYSB0b2tlbiBpc3N1ZWQgYXMgdGhl IHJlc3VsdCBvZiBhbiBhc3luY2hyb25vdXMgaW50ZXJhY3Rpb24sIGJ1dCB0aGF0J3Mgbm90IGEg YmlnIGlzc3VlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QnV0IHRoZSBBUyBvbiB0 aGUgcGhvbmUgc2VlbXMgbGlrZSBhIGhhcmRlciBudXQgdG8gY3JhY2ssIGF0IGxlYXN0IGF0IGZp cnN0IHNpZ2h0LiBJIHRoaW5rIHRoYXQgd291bGQgYmUgYXdlc29tZSwgYnV0IGl0IGdpdmVzIG1l IGhlYWRhY2hlcywgc28gSSB0aGluayBJJ2xsIHdvcmsgb24gZWFzaWVyIHN0dWZmIHJpZ2h0IG5v dyA7LSk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkZhYmllbiZuYnNwOyZuYnNwOzxi cj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJ4X2dtYWlsX3F1b3RlIj4NCjxk aXYgZGlyPSJsdHIiIGNsYXNzPSJ4X2dtYWlsX2F0dHIiPk9uIFRodSwgRmViIDQsIDIwMjEgYXQg NDozMCBQTSBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1 IiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZl cnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVy IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsNCiB3cm90ZTo8YnI+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJ4X2dtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBw eCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDoxcHg7IGJvcmRlci1sZWZ0LXN0eWxl OnNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpOyBwYWRkaW5nLWxlZnQ6 MWV4Ij4NCjxkaXY+T25lIG9mIHRoZSBiaWdnZXN0IGRyYXdiYWNrcyBvZiB0aGUgY3VycmVudCBh cHAtY2VudHJpYyBhcHByb2FjaGVzIGluIE9JREMgKHNlbGYtaXNzdWVkIE9QLCBvciBTSU9QKSBp cyB0aGF0IHRoZXkgZGVwZW5kIG9uIHVzaW5nIHRoZSBmcm9udCBjaGFubmVsIGFuZCBicm93c2Vy IHJlZGlyZWN0cyB0byBwYXNzIGV2ZXJ5dGhpbmcsIHdoaWNoIGlzIHNvbWV0aGluZyB0aGF0IEdO QVAgaXMgZGVsaWJlcmF0ZWx5IGdldHRpbmcgYXdheSBmcm9tDQogYnkgc3RhcnRpbmcgaW4gdGhl IGJhY2sgY2hhbm5lbC4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYXQgc2FpZCwgb25jZSBh IHJlcXVlc3QgaXMga2lja2VkIG9mZiBpbiBHTkFQLCB0aGUgaW50ZXJhY3Rpb24gYW5kIGZ1bGZp bGxtZW50IGNhbiBoYXBwZW4gdGhyb3VnaCBhbnkgbnVtYmVyIG9mIG1lYW5zLiBQYXJ0IG9mIHRo ZSB3b3JrIHRoYXTigJlzIGJlaW5nIGRvbmUgd2l0aCB0aGUg4oCcaW50ZXJhY3Rpb27igJ0gc2Vj dGlvbiBpcyBnb2luZyB0byBoZWxwIGZhY2lsaXRhdGUgdGhpcywgYW5kIEkgdGhpbmsgdGhhdCB0 aGVyZSBhcmUgc29tZQ0KIG90aGVyIHBvdGVudGlhbCBicmFuY2hlcyBoZXJlLjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+VG9rZW4gZGVsaXZlcnkgaXMgd2hlcmUgdGhpbmdzIGdldCBl eHRyYSB3ZWlyZCB0aG91Z2gg4oCUIHdlIGFyZSBleHBsaWNpdGx5IG5vdCBkZWxpdmVyaW5nIHRv a2VucyBpbiB0aGUgZnJvbnQgY2hhbm5lbCBpbiB0aGUgY29yZSBvZiBHTkFQLCB3ZeKAmXJlIHVz aW5nIHRoZSByZXNwb25zZSBmcm9tIHRoZSBjb250aW51YXRpb24gQVBJLiBPbmUgaWRlYSAodGhh dCBpc27igJl0IHBhcnRpY3VsYXJseSB3ZWxsIHRob3VnaHQgb3V0IGFuZCBoYXNu4oCZdA0KIGJl ZW4gaW1wbGVtZW50ZWQgYXQgYWxsKSBpcyB0byBoYXZlIGFuIGV4dGVuc2lvbiBkZWNsYXJlIGFu IGFsdGVybmF0aXZlIHJlc3BvbnNlIGZyb20gdGhlIOKAnGNvbnRpbnVl4oCdIHNlY3Rpb24gdGhh dOKAmXMgZGVmaW5lZCB0b2RheSwgd2hpY2ggcG9pbnRzIHRvIHRoZSBHTlBBIGNvbnRpbnVhdGlv biBBUEkuIElmIGFuIGV4dGVuc2lvbiBkZWZpbmVzIHNvbWUgYWx0ZXJuYXRpdmUgd2F5IHRvIGRl bGl2ZXIgdG9rZW5zLCB0aGF0IGNvdWxkIGxpdmUgYWxvbmdzaWRlDQogYSBjb250aW51YXRpb24g QVBJIGFuZCB0aGUgY2xpZW50IGNvdWxkIGluZGljYXRlIHN1cHBvcnQgZm9yIGl0IGluIGl0cyBp bml0aWFsIHJlcXVlc3QuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JbiBhbnkgZXZl bnQsIGFsdGVybmF0aXZlIGludGVyYWN0aW9uIGFuZCBkZWxpdmVyeSBtZXRob2RzIGFyZSBpbXBv cnRhbnQsIGFuZCBldmVuIGlmIHdlIGFyZW7igJl0IGdvaW5nIHRvIHN1cHBvcnQgZXZlcnkgbGFz dCBvbmUgb2YgdGhlbSBkaXJlY3RseSwgdGhlIHByb3RvY29sIGRlc2lnbiBzaG91bGQgYXQgbGVh c3QgYmUgYXdhcmUgb2YgdGhlbS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiZuYnNw O+KAlCBKdXN0aW48YnI+DQo8ZGl2Pjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRp dj5PbiBGZWIgNCwgMjAyMSwgYXQgODozNSBBTSwgRmFiaWVuIEltYmF1bHQgJmx0OzxhIGhyZWY9 Im1haWx0bzpmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb20iIHJlbD0ibm9yZWZlcnJlciBub3JlZmVy cmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5mYWJpZW4u aW1iYXVsdEBnbWFpbC5jb208L2E+Jmd0Ow0KIHdyb3RlOjwvZGl2Pg0KPGJyPg0KPGRpdj4NCjxk aXYgZGlyPSJsdHIiPkhpIFRvbSwmbmJzcDsNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlN1cmUs IGFueSBleHBlcmllbmNlIG9uIHRoYXQgd291bGQgYmUgZ3JlYXRseSBhcHByZWNpYXRlZCwgd2Un cmUgY2FsbGluZyBmb3IgaGVscCBoZXJlICh0aGUgcG9pbnQgYmVpbmcgdGhhdCBJIHN1c3BlY3Qg d2hhdCB0aGV5J3JlIGRvaW5nIGlzIG5vdCB0cml2aWFsKS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PkZhYmllbjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJ4X2dtYWls X3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJ4X2dtYWlsX2F0dHIiPk9uIFRodSwgRmVi IDQsIDIwMjEgYXQgMjoyMSBQTSBUb20gSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9tYXNj bGluZ2Fuam9uZXNAZ21haWwuY29tIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVy cmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+dGhvbWFzY2xpbmdhbmpvbmVz QGdtYWlsLmNvbTwvYT4mZ3Q7DQogd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFz cz0ieF9nbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVy LWxlZnQtd2lkdGg6MXB4OyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgYm9yZGVyLWxlZnQtY29s b3I6cmdiKDIwNCwyMDQsMjA0KTsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0iYXV0byI+ SSd2ZSBoYWQgc3VjaCBhbiBhcHAgd29ya2luZyBmb3Igb3ZlciBhIHllYXIuIFRoZXJlIGFyZSBp c3N1ZXMgd2hpY2ggYXJlIGJlaW5nIGFkZHJlc3NlZCBieSB0aGUgYnJvd3NlciBJbnRlcmFjdGlv biB0ZWFtIG9mIG9pZGMuPGJyPg0KPGJyPg0KPGRpdj50aHggLi5Ub20gKG1vYmlsZSk8L2Rpdj4N CjwvZGl2Pg0KPGJyPg0KPGRpdiBjbGFzcz0ieF9nbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRy IiBjbGFzcz0ieF9nbWFpbF9hdHRyIj5PbiBUaHUsIEZlYiA0LCAyMDIxLCAzOjEyIEFNIEZhYmll biBJbWJhdWx0ICZsdDs8YSBocmVmPSJtYWlsdG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tIiBy ZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayI+ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPC9hPiZndDsNCiB3cm90ZTo8 YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJ4X2dtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDoxcHg7IGJvcmRlci1sZWZ0 LXN0eWxlOnNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpOyBwYWRkaW5n LWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIiPkhpIEZyYW5jaXMsJm5ic3A7DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5JJ3ZlIHRyaWVkIGEgZmV3IHRoaW5ncyB3aXRoIHJlZ2FyZHMgdG8gdXNp bmcgdGhlIEFTIG9uIGEgcGhvbmUsIGJ1dCBpdCdzIHJlYWxseSBxdWl0ZSZuYnNwO2NvbXBsZXgu Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5NYWtpbmcgdGhhdCBydW4gb24g YSBwaG9uZSBjb21lcyB3aXRoIHF1aXRlIGEgYml0IG9mIHRyb3VibGUuIFRoZSBtb3N0IGRpZmZp Y3VsdCBwYXJ0IGlmIHRoYXQgd2UnZCBuZWVkIHRvIHVzZSBhIHNlY3VyZSBlbGVtZW50LCBidXQg anVzdCBpbnN0YWxsaW5nIGFuZCBob3N0aW5nIGEgaHR0cCBzZXJ2ZXIgc2VjdXJlbHkgaXMgbm90 IGEgc3RhbmRhcmQgc2V0dXAgYXQgYWxsLiBJIHN1Z2dlc3QgaW50ZXJlc3RlZCBwZW9wbGUgc3Rl cCBpbg0KIHRvIHdvcmsgb24gdGhpcywgYXMgd2UgYWxyZWFkeSBoYXZlIGEgbG90IG9mIHdvcmsg Zm9yIHRoZSAobW9yZSB1c3VhbCkgc2VydmVyIGNhc2UgYW5kIGFscmVhZHkgaGFuZGxlIGEgcHJp dmFjeSBwcmVzZXJ2aW5nIHNjaGVtZS4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PlBsZWFzZSBsZXQgdXMga25vdyB3aGF0IHlvdSB0aGluay48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkNoZWVycyw8L2Rpdj4NCjxkaXY+RmFiaWVuJm5ic3A7PC9kaXY+DQo8L2Rp dj4NCjxicj4NCjxkaXYgY2xhc3M9InhfZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xh c3M9InhfZ21haWxfYXR0ciI+T24gVHVlLCBOb3YgMjQsIDIwMjAgYXQgNTo1NSBBTSBGYWJpZW4g SW1iYXVsdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbSIgcmVs PSJub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPC9hPiZndDsN CiB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJ4X2dtYWlsX3F1b3RlIiBz dHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDoxcHg7IGJv cmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQp OyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJhdXRvIj4NCjxkaXY+SGkgRnJhbmNpcywN CjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5JJ3ZlIHRob3Vn aHQgYSBiaXQgbW9yZSB0byB3aGF0IHlvdSBzYWlkLiBJIHRoaW5rIEknbGwgZ2l2ZSBpdCBhIHRy eSBhcyBhIHNlcGFyYXRlIGV4cGVyaW1lbnQgKGluIGNvZGUsIG5vdCBpbiB0aGVvcnkpLiBOb3Qg dGhhdCBJIHdvdWxkIGV4cGVjdCBpdCB0byBiZSBpbmNsdWRlZCBpbiBHTkFQLCBidXQgSSBraW5k IG9mIGxpa2UgdGhlIGlkZWEgOi0pPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+ DQo8ZGl2IGRpcj0iYXV0byI+VGhlIGRpcmVjdCBpbXBhY3QgZm9yIEdOQVAgd291bGQgYmUgdG8g dGhpbmsgYWJvdXQgbXVsdGlwbGUgQVNzLiZuYnNwOzwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxi cj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPldpbGwgbGV0IHlvdSBrbm93LiZuYnNwOzwvZGl2 Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPkZhYmllbiZu YnNwOzwvZGl2Pg0KPGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0ieF9nbWFpbF9xdW90ZSI+DQo8ZGl2 IGRpcj0ibHRyIiBjbGFzcz0ieF9nbWFpbF9hdHRyIj5MZSBtZXIuIDE4IG5vdi4gMjAyMCDDoCAx MzowNiwgRnJhbmNpcyBQb3VhdGNoYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZwb0BhZG9yc3lzLmRl IiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZl cnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVy IG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5mcG9AYWRvcnN5cy5kZTwvYT4mZ3Q7DQogYSDD qWNyaXQmbmJzcDs6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0ieF9nbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6MXB4 OyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQs MjA0KTsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTox MnB0Ij5JdCB3b3VsZCBiZSBuaWNlIGlmIHRoZSBwcm90b2NvbCB3YXMgZGVzaWduZWQgYXQgbWFu eSBsYXllcnMgb2YgYWJzdHJhY3Rpb24uPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTJwdCI+PGJyPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxz YW5zLXNlcmlmOyBmb250LXNpemU6MTJwdCI+DQo8dWw+DQo8bGk+VGhlIGZpcnN0IGxheWVyIHNo YWxsIGRlc2lnbiBhYnN0cmFjdCBwcm90b2NvbCBmbG93cywgd2l0aG91dCBzcGVjaWZpY2F0aW9u IG9mIHRoZSBtb2RlIGFuZCBtZWNoYW5pc20gb2YgaW50ZXJhY3Rpb24uPC9saT48bGk+VGhlIHNl Y29uZCBsYXllciBjYW4gaW5zdGFudGlhdGUgdGhlIGZpcnN0IGxheWVyIGZvciBkZWRpY2F0ZWQg aW50ZXJhY3Rpb24uIEhlcmUgd2UgY2FuIHRhbGsgaHR0cCwgd2UgY2FuIGRlZmluZSBpbnRlcmFj dGlvbnMgdGhhdCBwcmVzdW1lIHNlcnZlciBiYXNlZCB0b2tlbiBnZW5lcmF0aW9uLCB3ZSBjYW4g ZGVmaW5lIGludGVyYWN0aW9uIHRoYXQgcnVuIG9uIHVzZXIgZGV2aWNlIGJhc2VkIHRva2VuIGdl bmVyYXRpb24uPC9saT48L3VsPg0KPGRpdj5UaGlzIGlzIGFsc28gdGhlIGZ1bmRhbWVudCBvZiB0 aGUgc3RydWN0dXJlIEkgcHJvcG9zZWQgZm9yIHRoZSBzcGVjICg8YSBocmVmPSJodHRwczovL2dp dGh1Yi5jb20vaWV0Zi13Zy1nbmFwL2duYXAtY29yZS1wcm90b2NvbC9pc3N1ZXMvMzAiIGlkPSJ4 X21fLTkxOTg4OTY5NDc1NjkyNTkxNjZnbWFpbC1tXzI0NTQ1NjU5OTM4MjQyMjUwNzZnbWFpbC1t XzQ4MTU0NjA3MTc4ODM0NjcwMTNtXzQ1ODgxMzc3MDE0MDk0MDI1NDVtXzM3NDA3MjMyNTMwODg2 OTM0OTZtXy05OTY3MTMxNjMxNjYyMTg5MmdtYWlsLW1fNDg5MTQ0MjIzMDQ5NTczNzAyMG1fLTgy MTg1NTI3ODgyODk5ODY5MDdtXy04NTE4ODE1OTc4MDkyNTQ2OTU0bV8zNTUwNDE5ODAwODM2NTY3 NTYwbV8tODI1MTE4NzU0NDIyOTM0MjA2N21fNjY0OTM5NjQ1ODEzMDEzNzg5Nm1fMzMwODgwMzA4 OTIwNzc4OTQ4OG1fLTQzNTQzNjU1NDg1OTYxNDUyOW1fMjg4ODE2NjE0MjQ4NTc1MDU5N2dtYWls LW1fNzkwMTM5NDI2NjgxNjAwNTI4MGdtYWlsLW1fLTY3MTgxODQ5OTk0NTI1MTIwNzdtXy0zMDA0 MjMyMjMxNDkzMjI5MzgxbV8tODg2MjU1MDk1ODY3NDUzMTMwNm1fNDU1MjY1Mzk4NDU2MjYzNTQ2 MW1fMzg3OTI5OTI0NDQxNTI3MTkwbV82NjYyMTA0MTkxMDAzODA2Mzg1Z21haWwtbV8tNTQyODM5 MDcwMzQxMDIzMzg4Z21haWwtbV8tNjE3NjA1Njk1NjQ3NDAxOTI5NGdtYWlsLW1fLTMwMzcxNjEy MDIyNDA1Nzg2ODVnbWFpbC1tXy03NTIwMzg5NDU3Mzc4ODA4NjY0Z21haWwtbV8tMzM0MjAyNDc4 MjMzMDU2OTI1NG1fODAxNDcwMDAzMjgzNTkxMjIwNGdtYWlsLW1fMTQyNjUxODczMjQ0ODAwNTU5 bV84MzQ4Nzk3NDQ1NDYwODA2MTc1TFBsbmszMzgzOTEiIHJlbD0ibm9yZWZlcnJlciBub3JlZmVy cmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL2lldGYtd2ctZ25hcC9nbmFwLWNvcmUt cHJvdG9jb2wvaXNzdWVzLzMwPC9hPikuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4v RnJhbmNpczwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJ4X21fLTkxOTg4OTY5NDc1NjkyNTkxNjZn bWFpbC1tXzI0NTQ1NjU5OTM4MjQyMjUwNzZnbWFpbC1tXzQ4MTU0NjA3MTc4ODM0NjcwMTNtXzQ1 ODgxMzc3MDE0MDk0MDI1NDVtXzM3NDA3MjMyNTMwODg2OTM0OTZtXy05OTY3MTMxNjMxNjYyMTg5 MmdtYWlsLW1fNDg5MTQ0MjIzMDQ5NTczNzAyMG1fLTgyMTg1NTI3ODgyODk5ODY5MDdtXy04NTE4 ODE1OTc4MDkyNTQ2OTU0bV8zNTUwNDE5ODAwODM2NTY3NTYwbV8tODI1MTE4NzU0NDIyOTM0MjA2 N21fNjY0OTM5NjQ1ODEzMDEzNzg5Nm1fMzMwODgwMzA4OTIwNzc4OTQ4OG1fLTQzNTQzNjU1NDg1 OTYxNDUyOW1fMjg4ODE2NjE0MjQ4NTc1MDU5N2dtYWlsLW1fNzkwMTM5NDI2NjgxNjAwNTI4MGdt YWlsLW1fLTY3MTgxODQ5OTk0NTI1MTIwNzdtXy0zMDA0MjMyMjMxNDkzMjI5MzgxbV8tODg2MjU1 MDk1ODY3NDUzMTMwNm1fNDU1MjY1Mzk4NDU2MjYzNTQ2MW1fMzg3OTI5OTI0NDQxNTI3MTkwbV82 NjYyMTA0MTkxMDAzODA2Mzg1Z21haWwtbV8tNTQyODM5MDcwMzQxMDIzMzg4Z21haWwtbV8tNjE3 NjA1Njk1NjQ3NDAxOTI5NGdtYWlsLW1fLTMwMzcxNjEyMDIyNDA1Nzg2ODVnbWFpbC1tXy03NTIw Mzg5NDU3Mzc4ODA4NjY0Z21haWwtbV8tMzM0MjAyNDc4MjMzMDU2OTI1NG1fODAxNDcwMDAzMjgz NTkxMjIwNGdtYWlsLW1fMTQyNjUxODczMjQ0ODAwNTU5bV84MzQ4Nzk3NDQ1NDYwODA2MTc1YXBw ZW5kb25zZW5kIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlh bCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOjEycHQiPjxicj4NCjwvZGl2Pg0KPGhy IHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazsgd2lkdGg6OTglIj4NCjxkaXYgaWQ9InhfbV8t OTE5ODg5Njk0NzU2OTI1OTE2NmdtYWlsLW1fMjQ1NDU2NTk5MzgyNDIyNTA3NmdtYWlsLW1fNDgx NTQ2MDcxNzg4MzQ2NzAxM21fNDU4ODEzNzcwMTQwOTQwMjU0NW1fMzc0MDcyMzI1MzA4ODY5MzQ5 Nm1fLTk5NjcxMzE2MzE2NjIxODkyZ21haWwtbV80ODkxNDQyMjMwNDk1NzM3MDIwbV8tODIxODU1 Mjc4ODI4OTk4NjkwN21fLTg1MTg4MTU5NzgwOTI1NDY5NTRtXzM1NTA0MTk4MDA4MzY1Njc1NjBt Xy04MjUxMTg3NTQ0MjI5MzQyMDY3bV82NjQ5Mzk2NDU4MTMwMTM3ODk2bV8zMzA4ODAzMDg5MjA3 Nzg5NDg4bV8tNDM1NDM2NTU0ODU5NjE0NTI5bV8yODg4MTY2MTQyNDg1NzUwNTk3Z21haWwtbV83 OTAxMzk0MjY2ODE2MDA1MjgwZ21haWwtbV8tNjcxODE4NDk5OTQ1MjUxMjA3N21fLTMwMDQyMzIy MzE0OTMyMjkzODFtXy04ODYyNTUwOTU4Njc0NTMxMzA2bV80NTUyNjUzOTg0NTYyNjM1NDYxbV8z ODc5Mjk5MjQ0NDE1MjcxOTBtXzY2NjIxMDQxOTEwMDM4MDYzODVnbWFpbC1tXy01NDI4MzkwNzAz NDEwMjMzODhnbWFpbC1tXy02MTc2MDU2OTU2NDc0MDE5Mjk0Z21haWwtbV8tMzAzNzE2MTIwMjI0 MDU3ODY4NWdtYWlsLW1fLTc1MjAzODk0NTczNzg4MDg2NjRnbWFpbC1tXy0zMzQyMDI0NzgyMzMw NTY5MjU0bV84MDE0NzAwMDMyODM1OTEyMjA0Z21haWwtbV8xNDI2NTE4NzMyNDQ4MDA1NTltXzgz NDg3OTc0NDU0NjA4MDYxNzVkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+DQo8Zm9udCBmYWNlPSJD YWxpYnJpLCBzYW5zLXNlcmlmIiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxiPkZyb206PC9iPiBG YWJpZW4gSW1iYXVsdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZhYmllbi5pbWJhdWx0QGdtYWlsLmNv bSIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVm ZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVy cmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5mYWJpZW4uaW1iYXVsdEBn bWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDE4 LCAyMDIwIDY6MzUgQU08YnI+DQo8Yj5Ubzo8L2I+IEZyYW5jaXMgUG91YXRjaGEgJmx0OzxhIGhy ZWY9Im1haWx0bzpmcG9AYWRvcnN5cy5kZSIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9y ZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVm ZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVy cmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0i X2JsYW5rIj5mcG9AYWRvcnN5cy5kZTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJt YWlsdG86dHhhdXRoQGlldGYub3JnIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVy cmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxh bmsiPg0KdHhhdXRoQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRm Lm9yZyIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZl cnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj50eGF1dGhAaWV0Zi5v cmc8L2E+Jmd0OzsNCiBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBn bWFpbC5jb20iIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJk dEBnbWFpbC5jb208L2E+Jmd0OzsNCiBUb20gSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9t YXNjbGluZ2Fuam9uZXNAZ21haWwuY29tIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZl cnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiPnRob21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb208L2E+Jmd0OzsNCiBEZW5pcyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRlbmlzLmlldGZAZnJlZS5mciIgcmVsPSJub3JlZmVycmVyIG5vcmVm ZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVy cmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIi IHRhcmdldD0iX2JsYW5rIj5kZW5pcy5pZXRmQGZyZWUuZnI8L2E+Jmd0OzsNCiBKdXN0aW4gUmlj aGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiByZWw9Im5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbR05BUF0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtZ25hcC1jb3JlLXByb3Rv Y29sLTAwPC9mb250Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgZGly PSJsdHIiPldvdWxkIG1ha2Ugc2Vuc2UsIGJ1dCBub3Qgc28gZWFzeSBhcyB3ZSByZWx5IGhlYXZp bHkgb24gSFRUUC4gSGVuY2UgdGhlIGRpc2N1c3Npb24gYWJvdXQgZGVlcCBsaW5rcyBhbmQgc28g b24uDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BbiBhbHRlcm5hdGl2ZSBtaWdodCBiZSBwcm92 aWRlZCBieSB3YXNtL3dhc2kgKHJ1bm5pbmcgYSBsb2NhbCBzYW5kYm94IG9uIHlvdXIgcGhvbmUs IGZvciB5b3VyIG93biBBUyksIGJ1dCBpdCdzIHJlYWxseSBlYXJseSBzdGFnZS4gVGhpcyBhbHNv IHBvc2VzIGFub3RoZXIgcXVlc3Rpb24gdGhhdCBEZW5pcyBoYXMgcHV0IGZvcndhcmQsIGkuZS4g aG93IGRvIHdlIGhhbmRsZSB0aGUgbXVsdGlwbGUgQVMgc2NlbmFyaW8gKGxpa2VseSB0bw0KIG9j Y3VyIHRoZW4pLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RmFiaWVuJm5i c3A7PC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5PbiBXZWQsIE5v diAxOCwgMjAyMCBhdCAxMjoxNiBQTSBGcmFuY2lzIFBvdWF0Y2hhICZsdDs8YSBocmVmPSJtYWls dG86ZnBvQGFkb3JzeXMuZGUiIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+ ZnBvQGFkb3JzeXMuZGU8L2E+Jmd0Ow0KIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6MXB4OyBi b3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0 KTsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgaWQ9InhfbV8tOTE5 ODg5Njk0NzU2OTI1OTE2NmdtYWlsLW1fMjQ1NDU2NTk5MzgyNDIyNTA3NmdtYWlsLW1fNDgxNTQ2 MDcxNzg4MzQ2NzAxM21fNDU4ODEzNzcwMTQwOTQwMjU0NW1fMzc0MDcyMzI1MzA4ODY5MzQ5Nm1f LTk5NjcxMzE2MzE2NjIxODkyZ21haWwtbV80ODkxNDQyMjMwNDk1NzM3MDIwbV8tODIxODU1Mjc4 ODI4OTk4NjkwN21fLTg1MTg4MTU5NzgwOTI1NDY5NTRtXzM1NTA0MTk4MDA4MzY1Njc1NjBtXy04 MjUxMTg3NTQ0MjI5MzQyMDY3bV82NjQ5Mzk2NDU4MTMwMTM3ODk2bV8zMzA4ODAzMDg5MjA3Nzg5 NDg4bV8tNDM1NDM2NTU0ODU5NjE0NTI5bV8yODg4MTY2MTQyNDg1NzUwNTk3Z21haWwtbV83OTAx Mzk0MjY2ODE2MDA1MjgwZ21haWwtbV8tNjcxODE4NDk5OTQ1MjUxMjA3N21fLTMwMDQyMzIyMzE0 OTMyMjkzODFtXy04ODYyNTUwOTU4Njc0NTMxMzA2bV80NTUyNjUzOTg0NTYyNjM1NDYxbV8zODc5 Mjk5MjQ0NDE1MjcxOTBtXzY2NjIxMDQxOTEwMDM4MDYzODVnbWFpbC1tXy01NDI4MzkwNzAzNDEw MjMzODhnbWFpbC1tXy02MTc2MDU2OTU2NDc0MDE5Mjk0Z21haWwtbV8tMzAzNzE2MTIwMjI0MDU3 ODY4NWdtYWlsLW1fLTc1MjAzODk0NTczNzg4MDg2NjRnbWFpbC1tXy0zMzQyMDI0NzgyMzMwNTY5 MjU0bV84MDE0NzAwMDMyODM1OTEyMjA0Z21haWwtbV8xNDI2NTE4NzMyNDQ4MDA1NTltXzgzNDg3 OTc0NDU0NjA4MDYxNzV4X2dtYWlsLW1fLTcxNTI0MTg4ODI4NzUwODYzODJhcHBlbmRvbnNlbmQi IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyBm b250LXNpemU6MTJwdCI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmks QXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMnB0Ij5XZSBhcmUgZHJpZnRp bmcgYXdheSBmcm9tIHRoZSBvcmlnaW5hbCBwcm9ibGVtIHNwYWNlLjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1z aXplOjEycHQiPg0KPHVsPg0KPGxpPk15IG9yaWdpbmFsIG1lbnRpb24gd2FzIGFib3V0IHRoZSAm cXVvdDtQT1NUJnF1b3Q7IHJlcXVlc3QsIHRoYXQgc3Vic3VtZXMgdGhhdCB0aGUgJnF1b3Q7QVMm cXVvdDsgaXMgYSAmcXVvdDtTZXJ2ZXImcXVvdDsuIERlc2lnbmluZyBhIG5ldyBwcm90b2NvbCwg d2UgY2Fubm90IGFmZm9yZCB0aGlzIGxpbWl0YXRpb24uPC9saT48bGk+SSBqdXN0IG1lbnRpb25l ZCBTSU9QIHRvIHNob3cgYSBrbm93biBhbmQgY2xvc2VkIGV4YW1wbGU/IExldCB1cyBub3QgZm9j dXMgb24gdGhlIGRldmljZSBsb2NhbCBkaXNjb3Zlcnkgc2NoZW1lIChsaWtlIG9wZW5pZDopIGZv ciBub3cuPC9saT48bGk+QXMgY2FwYWJpbGl0eSBvZiBob2xkaW5nIHByaXZhdGUga2V5cyBvbiB1 c2VyIGRldmljZSBldm9sdmVzLCBzZXJ2ZXItYmFzZWQgaXNzdWluZyBvZiB0b2tlbiB3aWxsIGJl IGZhZGluZyBvdXQgZ2l2aW5nIHdheSB0byBkZXZpY2UgbG9jYWwgZ2VuZXJhdGlvbiBvZiB0b2tl bi48L2xpPjwvdWw+DQo8ZGl2PldoaWxlIGRlc2lnbmluZyBHTkFQLCBsZXQgdXMgYXNzdW1lIHRo ZSBBUy1Sb2xlIGNhbiBiZSBleGVyY2lzZWQgb24gYSB1c2VyIGRldmljZSBhbmQgZGVzaWduIHRo ZSBwcm90b2NvbCB0byBob25vciB0aGF0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdj4vRnJhbmNpczwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250 LXNpemU6MTJwdCI+PC9kaXY+DQo8aHIgc3R5bGU9ImRpc3BsYXk6aW5saW5lLWJsb2NrOyB3aWR0 aDo5OCUiPg0KPGRpdiBpZD0ieF9tXy05MTk4ODk2OTQ3NTY5MjU5MTY2Z21haWwtbV8yNDU0NTY1 OTkzODI0MjI1MDc2Z21haWwtbV80ODE1NDYwNzE3ODgzNDY3MDEzbV80NTg4MTM3NzAxNDA5NDAy NTQ1bV8zNzQwNzIzMjUzMDg4NjkzNDk2bV8tOTk2NzEzMTYzMTY2MjE4OTJnbWFpbC1tXzQ4OTE0 NDIyMzA0OTU3MzcwMjBtXy04MjE4NTUyNzg4Mjg5OTg2OTA3bV8tODUxODgxNTk3ODA5MjU0Njk1 NG1fMzU1MDQxOTgwMDgzNjU2NzU2MG1fLTgyNTExODc1NDQyMjkzNDIwNjdtXzY2NDkzOTY0NTgx MzAxMzc4OTZtXzMzMDg4MDMwODkyMDc3ODk0ODhtXy00MzU0MzY1NTQ4NTk2MTQ1MjltXzI4ODgx NjYxNDI0ODU3NTA1OTdnbWFpbC1tXzc5MDEzOTQyNjY4MTYwMDUyODBnbWFpbC1tXy02NzE4MTg0 OTk5NDUyNTEyMDc3bV8tMzAwNDIzMjIzMTQ5MzIyOTM4MW1fLTg4NjI1NTA5NTg2NzQ1MzEzMDZt XzQ1NTI2NTM5ODQ1NjI2MzU0NjFtXzM4NzkyOTkyNDQ0MTUyNzE5MG1fNjY2MjEwNDE5MTAwMzgw NjM4NWdtYWlsLW1fLTU0MjgzOTA3MDM0MTAyMzM4OGdtYWlsLW1fLTYxNzYwNTY5NTY0NzQwMTky OTRnbWFpbC1tXy0zMDM3MTYxMjAyMjQwNTc4Njg1Z21haWwtbV8tNzUyMDM4OTQ1NzM3ODgwODY2 NGdtYWlsLW1fLTMzNDIwMjQ3ODIzMzA1NjkyNTRtXzgwMTQ3MDAwMzI4MzU5MTIyMDRnbWFpbC1t XzE0MjY1MTg3MzI0NDgwMDU1OW1fODM0ODc5NzQ0NTQ2MDgwNjE3NXhfZ21haWwtbV8tNzE1MjQx ODg4Mjg3NTA4NjM4MmRpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj4NCjxmb250IGZhY2U9IkNhbGli cmksIHNhbnMtc2VyaWYiIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGI+RnJvbTo8L2I+IFRYQXV0 aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnIiByZWw9Im5vcmVm ZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVy cmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPnR4YXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZn dDsNCiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFy ZHRAZ21haWwuY29tIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVm ZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVy cmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmRpY2su aGFyZHRAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92ZW1i ZXIgMTcsIDIwMjAgMToyOCBQTTxicj4NCjxiPlRvOjwvYj4gVG9tIEpvbmVzICZsdDs8YSBocmVm PSJtYWlsdG86dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbSIgcmVsPSJub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZl cnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJy ZXIiIHRhcmdldD0iX2JsYW5rIj50aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tPC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+IEZhYmllbiBJbWJhdWx0ICZsdDs8YSBocmVmPSJtYWlsdG86ZmFiaWVu LmltYmF1bHRAZ21haWwuY29tIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVy IG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBu b3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9y ZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi PmZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbTwvYT4mZ3Q7Ow0KIERlbmlzICZsdDs8YSBocmVmPSJt YWlsdG86ZGVuaXMuaWV0ZkBmcmVlLmZyIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZl cnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiPmRlbmlzLmlldGZAZnJlZS5mcjwvYT4mZ3Q7Ow0KIEdOQVAgTWFpbGluZyBMaXN0ICZs dDs8YSBocmVmPSJtYWlsdG86dHhhdXRoQGlldGYub3JnIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZl cnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVy IG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciIg dGFyZ2V0PSJfYmxhbmsiPnR4YXV0aEBpZXRmLm9yZzwvYT4mZ3Q7Ow0KIEp1c3RpbiBSaWNoZXIg Jmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHJlbD0ibm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZl cnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVy IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtHTkFQXSBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1nbmFwLWNvcmUtcHJvdG9jb2wt MDA8L2ZvbnQ+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0 ciI+R290IGl0LiZuYnNwOzxicj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNvIHdlYiBhcHBz IGludm9rZSBhIG9wZW5pZDogZGVlcCBsaW5rIGFuZCBob3BlIHRoZXJlIGlzIGFuIGFwcCB0byBo YW5kbGUgdGhlIG9wZW5pZDogc2NoZW1lPyAuLi4gYW5kIHRoYXQgaXQgaXMgdGhlIHVzZXIncyB3 YWxsZXQgcmF0aGVyIHRoYW4gc29tZSBtYWx3YXJlIHRoYXQgaGFzIHJlZ2lzdGVyZWQgb3Blbmlk OiBvbiB0aGUgbW9iaWxlIGRldmljZT88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkEg bmF0aXZlIGFwcCBjYW4gYXR0ZW1wdCB0byBvcGVuIGEgZGVlcCBsaW5rIGFzc29jaWF0ZWQgd2l0 aCBhbiBhcHAsIGFuZCB3aWxsIGZhaWwgaWYgdGhlIGFwcCBpcyBub3QgdGhlcmUuIElmIHRoZSBh cHAgaXMgdGhlcmUsIGl0IHdpbGwgYmUgb3BlbmVkLCBzbyB0aGlzIGNhbid0IGJlIHVzZWQgdG8g c2lsZW50bHkgdGVzdCBpZiBhbiBhcHAgaXMgcHJlc2VudCwgYnV0IGl0IGRvZXMgYWxsb3cgYSBu YXRpdmUgYXBwIHRvIHByb3ZpZGUgYW4NCiBhbHRlcm5hdGl2ZSBleHBlcmllbmNlIGlmIGFuIGFw cCBpcyBub3QgcHJlc2VudC4gSSBkb24ndCB0aGluayB0aGlzIHdvcmtzIHdpdGggY3VzdG9tIHNj aGVtZXMgLi4uIGFuZCBJIGRvbid0IGtub3cgaG93IGl0IGNvdWxkIHdvcmsgZnJvbSBhIHdlYiBh cHAgb24gdGhlIHBob25lIHdpdGggdGhlIGN1cnJlbnQgU2FmYXJpIEFQSXMuPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5BcHBsZSB3YXJucyBhZ2FpbnN0IHVzaW5nIGN1c3RvbSBzY2hl bWVzIFsxXSAuLi4gYnV0IHBlcmhhcHMgdGhleSBjYW4gYmUgY29udmluY2VkIHRvIG1ha2Ugb3Bl bmlkOiBhIG1hbmFnZWQgc2NoZW1lIHNpbWlsYXIgdG8gbWFpbHRvOiwgdGVsOiwgc21zOiwgZmFj ZXRpbWU6ID88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlsxXSZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vZGV2ZWxvcGVyLmFwcGxlLmNvbS9kb2N1bWVudGF0aW9uL3hjb2RlL2FsbG93aW5n X2FwcHNfYW5kX3dlYnNpdGVzX3RvX2xpbmtfdG9feW91cl9jb250ZW50L2RlZmluaW5nX2FfY3Vz dG9tX3VybF9zY2hlbWVfZm9yX3lvdXJfYXBwIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBu b3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9y ZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVm ZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vZGV2ZWxvcGVyLmFwcGxlLmNvbS9kb2N1bWVudGF0aW9uL3hjb2Rl L2FsbG93aW5nX2FwcHNfYW5kX3dlYnNpdGVzX3RvX2xpbmtfdG9feW91cl9jb250ZW50L2RlZmlu aW5nX2FfY3VzdG9tX3VybF9zY2hlbWVfZm9yX3lvdXJfYXBwPC9hPjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgaHNwYWNlPSJzdHJlYWst cHQtbWFyayIgc3R5bGU9Im1heC1oZWlnaHQ6MXB4Ij48aW1nIGFsdD0iIiBzdHlsZT0id2lkdGg6 MHB4OyBtYXgtaGVpZ2h0OjBweDsgb3ZlcmZsb3c6aGlkZGVuIiBzcmM9Imh0dHBzOi8vbWFpbGZv b2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNE JmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlkPTAxMTQ5MGJlLWQzYTAtNGIyYy04YWJiLWU1 MTE3NWUzYWUxOSI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiNmZmZmZmYiPuGQpzwvZm9udD48L2Rp dj4NCjxicj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5PbiBUdWUsIE5vdiAxNywgMjAyMCBhdCAx MDowNiBBTSBUb20gSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9tYXNjbGluZ2Fuam9uZXNA Z21haWwuY29tIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVy IG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBu b3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPnRob21hc2Ns aW5nYW5qb25lc0BnbWFpbC5jb208L2E+Jmd0Ow0KIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6 MXB4OyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwy MDQsMjA0KTsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+WW91IGFy ZSAtIHRoYXQgaXMgbm90IHN0YW5kYXJkIHdoaWNoIGlzIG9wZWluZDovLzwvZGl2Pg0KPGRpdj5U aGlzIGlzIHRoZSBvbmUgc3RlcCB0aGF0IHN0aWxsIG5lZWRzIHRvIGJlIG9wdGltaXplZCBmb3Ig U0lPUCB0byBoYXZlIGdvb2QgVVguPGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGly PSJsdHIiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2PlBlYWNlIC4udG9tPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGRpdj4NCjxkaXYg ZGlyPSJsdHIiPk9uIFR1ZSwgTm92IDE3LCAyMDIwIGF0IDk6NTkgQU0gRGljayBIYXJkdCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiByZWw9Im5vcmVmZXJyZXIgbm9y ZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVm ZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVy cmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsNCiB3cm90ZTo8 YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7 IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IGJvcmRlci1s ZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9 Imx0ciI+SGkgVG9tDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHdhdGNoZWQgeW91ciB2aWRl byAoSSB3YXRjaGVkIGF0IDJYIHNwZWVkKTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ TG9va3MgbGlrZSB0aGUgZW1wbG95bWVudCB3ZWJzaXRlIGFwcCB0aGF0IGlzIHVzaW5nIGxvY2Fs aG9zdDo4NzY1IHRvIGNvbW11bmljYXRlIHdpdGggdGhlIHdhbGxldC4gQW0gSSBjb3JyZWN0Pzwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+L0RpY2smbmJzcDs8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBoc3BhY2U9InN0cmVhay1wdC1tYXJrIiBzdHlsZT0ibWF4LWhlaWdodDoxcHgiPjxpbWcg YWx0PSIiIHN0eWxlPSJ3aWR0aDowcHg7IG1heC1oZWlnaHQ6MHB4OyBvdmVyZmxvdzpoaWRkZW4i IHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lY SmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9emVyb2NvbnRlbnQmYW1wO2d1aWQ9MTFhNjJj ZTYtOWI0YS00ZDVmLTg2YzUtZDJjMTE0Mzk1YWVlIj48Zm9udCBzaXplPSIxIiBjb2xvcj0iI2Zm ZmZmZiI+4ZCnPC9mb250PjwvZGl2Pg0KPGJyPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPk9uIFR1 ZSwgTm92IDE3LCAyMDIwIGF0IDk6NDYgQU0gVG9tIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86 dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbSIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdl dD0iX2JsYW5rIj50aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tPC9hPiZndDsNCiB3cm90ZTo8 YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7 IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IGJvcmRlci1s ZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9 Imx0ciI+V2VsbCwgaGVyZSdzIGEgZGVtby4gTm90ZSB0aGF0IGluIHRoaXMgY2FzZSB0aGUgQVMg aXMgbm90IG9ubGluZSBhbGwgb2YgdGhlIHRpbWUsIHNvIGl0IGlzIHJlYWxseSBpbXBsaWNpdCBm bG93IGFuZCB0aGUgT0lEQyBpZC10b2tlbiBjb21lcyBmcm9tIHRoZSBzaW9wIGRldmljZSBkaXJl Y3RseS4NCjxkaXY+KHdoZXRoZXIgdGhpcyBpcyBmcm9udC1jaGFubmVsIG9yIGJhY2sgY2hhbm5l bCBpcyBubyBsb25nZXIgYW4gaW50ZXJlc3RpbmcgcXVlc3Rpb24uKTxicj4NCjxkaXY+Tm93IGlm IGFuIGFsd2F5cy1vbiBBUyBpcyByZXF1aXJlZCwgdGhhdCBpcyBwb3NzaWJsZSwgYnV0IHByb2Jh Ymx5IGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBlZmZvcnQgYW5kIHdvdWxkIHJlcXVpcmUgc29t ZXRoaW5nIGxpa2UgYW4gYWdlbnQtaW4tdGhlLXNreSZuYnNwOyh3aXRoIGRpYW1vbmRzKS48L2Rp dj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij5oZXJlIGlzIHRoZSBsaW5rIHRv IHRoZSA5IG1pbiB2aWRlbyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UudXMvdjIvdXJsP3U9aHR0cHMtM0FfX3lvdXR1LmJlX1RxNGh3N1g1U1cwJmFt cDtkPUR3TUZhUSZhbXA7Yz0ycGxJM2hYSDh3dzNqMmc4cFYxOVFISWY0U21LX0ktRW9sX3A5UDBD dHRFJmFtcDtyPUQ1bG5mb2EyTVZaV0VMcVZiYno3MW9vZWxiUDdyVkdDakdEU0JOdlVwWVEmYW1w O209aXhzdWRHU3JfZGhHLVNMaWF0YjRTejlGV3NsbXl3bll5WkFPTGdaeGhsOCZhbXA7cz1qZExM eTBHMUpUUUNBT0JaNlBlVWdJMGtpQ3RWSlhycnUwVlRvWVdsTlo4JmFtcDtlPSIgcmVsPSJub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZl cnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVy IG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iZm9udC1zaXplOjE0cHgiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTJwdCI+aHR0cHM6Ly88c3Bhbj55b3V0dTwvc3Bhbj4uPHNwYW4+ YmU8L3NwYW4+L1RxNGh3N1g1U1cwPC9zcGFuPjwvYT48YnIgY2xlYXI9ImFsbCI+DQo8ZGl2Pg0K PGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+UGVhY2UgLi50b208L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxi cj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5PbiBUdWUsIE5vdiAxNywgMjAyMCBhdCA5OjIwIEFN IEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHJlbD0i bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZl cnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsN CiB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MHB4IDBweCAw cHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7 IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0K PGRpdj5VbHRpbWF0ZWx5LCBpbiBtb3N0IHNpdHVhdGlvbnMgbGlrZSB0aGVzZSBpbiB0aGUgcmVh bCB3b3JsZCwgdGhlIGh1cmRsZSBpc27igJl0IHRlY2huaWNhbCBjb21wYXRpYmlsaXR5IHNvIG11 Y2ggYXMgaXQgaXMgdHJ1c3QgY29tcGF0aWJpbGl0eS4gVGhlIFJQIChjbGllbnQpIG5lZWRzIHRv IGhhdmUgc29tZSBpbmNlbnRpdmUgdG8gdHJ1c3QgdGhlIGFzc2VydGlvbnMgYW5kIGlkZW50aXR5 IGluZm9ybWF0aW9uIHRoYXTigJlzIGNvbWluZyBmcm9tDQogdGhlIEFTLiBUaGUgc2FtZSBpcyB0 cnVlIGZvciBhbiBSUyB0cnVzdGluZyB0b2tlbnMgZnJvbSB0aGUgQVMuIFRoZSBoYXJkIHF1ZXN0 aW9uIGlzIGxlc3Mg4oCcaG934oCdIHRvIGRvIHRoYXQgKHdoaWNoIFNTSSBhbnN3ZXJzKSwgYnV0 IG1vcmUg4oCcd2h54oCdIHRvIGRvIHRoYXQgKHdoaWNoIFNTSSBkb2VzbuKAmXQgYW5zd2VyIHZl cnkgd2VsbCwgYmVjYXVzZSBpdOKAmXMgYSBoYXJkIHF1ZXN0aW9uKS4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PlN0aWxsOiBpdOKAmXMgZGVmaW5pdGVseSBhIHF1ZXN0aW9uIGFib3V0IGhvdyB0 byBzdXBwb3J0IHRoaXMg4oCcQVMgb24gZGV2aWNl4oCdIGVsZW1lbnQuIFdl4oCZdmUgZ290IHRo ZSBzdGFydCBvZiBpdCBtb3JlIHRoYW4gT0F1dGgyL09JREMgaGF2ZSBieSBhbGxvd2luZyB0aGUg Ym9vdHN0cmFwIG9mIHRoZSBwcm9jZXNzIGZyb20gYSBzdGFydGluZyBjYWxsOiB0aGUgaW50ZXJh Y3Rpb24gYW5kIGNvbnRpbnVhdGlvbiBVUklzIGhhbmRlZCBiYWNrIGJ5DQogdGhlIEFTIGRvbuKA mXQgbmVlZCB0byBiZSB0aGUgc2FtZSBVUklzIHRoYXQgdGhlIGNsaWVudCBzdGFydHMgd2l0aCwg c28ganVzdCBsaWtlIFNJT1AgdGhlIHByb2Nlc3MgY2FuIHN0YXJ0IGluIEhUVFAgYW5kIHBvdGVu dGlhbGx5IG1vdmUgdG8gb3RoZXIgY29tbXVuaWNhdGlvbiBjaGFubmVscy4gQSBtYWpvciBkaWZm ZXJlbmNlIGlzIHRoYXQgd2UgYXJlbuKAmXQgZGVwZW5kZW50IG9uIHRoZSBhc3N1bXB0aW9uIHRo YXQgdGhlIHVzZXIgd2lsbCBhbHdheXMNCiBiZSBpbiBhIGJyb3dzZXIgYXQgc29tZSBzdGFnZSwg YW5kIHNvIHRoZSB3aG9sZSByYWZ0IG9mIGZyb250LWNoYW5uZWwgbWVzc2FnZXMgdGhhdCBTSU9Q IHJlbGllcyBvbiBkb2VzbuKAmXQgZmx5LiBUaGF0IHNhaWQsIHdl4oCZdmUgZ290IGFuIG9wcG9y dHVuaXR5IHRvIG1vcmUgZXhwbGljaXRseSBvcGVuIHVwIGFsdGVybmF0aXZlIGNvbW11bmljYXRp b24gY2hhbm5lbHMgaGVyZSwgYW5kIHRoYXTigJlzIHNvbWV0aGluZyBJ4oCZZCBsaWtlIHRvIHNl ZSBlbmdpbmVlcmVkLA0KIGV2ZW4gaWYgaXTigJlzIGFuIGV4dGVuc2lvbi4gSeKAmWQgbG92ZSB0 byBzZWUgYSBjb25jcmV0ZSBwcm9wb3NhbCBhcyB0byBob3cgdGhhdCB3b3VsZCB3b3JrIG92ZXIg c3BlY2lmaWMgcHJvdG9jb2xzLCBzdGFydGluZyB3aXRoIHdoYXQgd2XigJl2ZSBnb3QgdG9kYXku Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDvigJQgSnVzdGluPGJy Pg0KPGRpdj48YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+T24gTm92IDE3LCAy MDIwLCBhdCAxMjowMyBQTSwgRmFiaWVuIEltYmF1bHQgJmx0OzxhIGhyZWY9Im1haWx0bzpmYWJp ZW4uaW1iYXVsdEBnbWFpbC5jb20iIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVy IG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBu b3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFu ayI+ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPC9hPiZndDsNCiB3cm90ZTo8L2Rpdj4NCjxicj4N CjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5IaSBEZW5pcywgaGkgRnJhbmNpcywmbmJzcDsNCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkF0IHNvbWUgcG9pbnQgaW50ZWdyYXRpb24gd2l0aCBTU0kgKG9u IHRoZSBhdXRoZW50aWNhdGlvbiBzaWRlKSB3aWxsIHByb2JhYmx5IG9jY3VyLCBpbmNsdWRpbmcg YW1vbmdzdCBvdGhlciBwb3NzaWJpbGl0aWVzIFNJT1AgKHNpbmNlIHRoZXkgd29yayB3aXRoIE9w ZW5JRCBhIHBhcnQgb2YgdGhlIHdvcmsgd2lsbCBwcm9iYWJseSBiZSBtYWRlIGVhc2llcikuJm5i c3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGF0IGJlaW5nIHNhaWQsIERlbmlz IGlzIHJpZ2h0LiBJdCdzIG5vdCBhbiBBUy4gVGVjaG5pY2FsbHkgaXQncyBlbnRpcmVseSBwb3Nz aWJsZSB0byByZWx5IG9uIGEgZGVjZW50cmFsaXplZCB3YWxsZXQgKGZvciBpbnN0YW5jZSBvbiB5 b3VyIHBob25lKSBhbmQgYSBjZW50cmFsaXplZCBBUy4gSSBrbm93IG9mIGEgZmV3IHN0dWRpZXMg b24gaG93IHRvIGRlY2VudHJhbGl6ZSB0aGUgQVMgaXRzZWxmIChmb3IgaW5zdGFuY2UmbmJzcDs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFyZGpvbm8tb2F1dGgt ZGVjZW50cmFsaXplZC0wMiIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBu b3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9y ZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVm ZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFyZGpvbm8tb2F1dGgtZGVjZW50cmFs aXplZC0wMjwvYT4pLjwvZGl2Pg0KPGRpdj5NYXliZSBpdCBleGlzdHMsIGJ1dCBJJ20gc3RpbGwg bG9va2luZyBmb3IgcmVhbCBzY2VuYXJpb3MgKG9yIGV2ZW4gYXJjaGl0ZWN0dXJlcykgd2hlcmUg YW4gQVMgaXMgZGVwbG95ZWQgZGlyZWN0bHkgb24gYSBwaG9uZSwgYW5kIHVuZGVyIHRoZSBzb2xl IGF1dGhvcml0eSBvZiB0aGUgUk8sIHdoaWxlIGJlaW5nIGNvbXBhdGlibGUgd2l0aCB0aGUgcmVz dCBvZiB0aGUgd29ybGQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DaGVl cnMsPC9kaXY+DQo8ZGl2PkZhYmllbjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8ZGl2Pg0KPGRpdiBk aXI9Imx0ciI+T24gVHVlLCBOb3YgMTcsIDIwMjAgYXQgNTo0NSBQTSBEZW5pcyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmRlbmlzLmlldGZAZnJlZS5mciIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdl dD0iX2JsYW5rIj5kZW5pcy5pZXRmQGZyZWUuZnI8L2E+Jmd0Ow0KIHdyb3RlOjxicj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxl ZnQtd2lkdGg6MXB4OyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6 cmdiKDIwNCwyMDQsMjA0KTsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2Pg0KPGRpdj5IZWxsbyZu YnNwOyBGcmFuY2lzLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2VlIHR3byBjb21t ZW50cyBpbiBsaW5lLjxicj4NCjwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXItY29sb3I6cmdiKDIwMCwyMDAsMjAwKTsgYm9yZGVyLWxlZnQtd2lkdGg6M3B4OyBi b3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgcGFkZGluZy1sZWZ0OjFleDsgbWFyZ2luLWxlZnQ6MC44 ZXg7IGNvbG9yOnJnYigxMDIsMTAyLDEwMikiPg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9Im1hcmdp bjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1zaXplOjEycHQ7IGZvbnQtZmFt aWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBweCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyB0ZXh0LWFsaWdu OmxlZnQ7IGJhY2tncm91bmQtY29sb3I6d2hpdGUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+ QikgQ3VycmVudCBEb2N1bWVudDwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGJyPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48Zm9udD5Sb2xlcyBkZXNjcmlwdGlvbiBz aGFsbCBub3QgaG9sZCBhbnkgYXNzdW1wdGlvbiBvbiB0aGUgcGh5c2ljYWwgc3RydWN0dXJlIG9m IHRoZSBwYXJ0eSBmdWxmaWxsaW5nIHRoZSByb2xlcy48L2ZvbnQ+DQo8ZGl2IHN0eWxlPSJtYXJn aW46MHB4Ij48Zm9udCBjb2xvcj0icmVkIj5bRkldIG5vdCBzdXJlIHdoYXQgeW91IG1lYW48L2Zv bnQ+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxNXB4OyBiYWNrZ3JvdW5kLWNvbG9y OnJnYigyNTUsMjU1LDI1NSkiPiZuYnNwO1tGUF0gZm9yIGV4YW1wbGUsIHdlIGFzc3VtZSB0aGUg QVMgaXMgYSBzZXJ2ZXIhIEluIG1vc3QgU1NJIGJhc2VkIHVzZSBjYXNlcywgdGhlIEFTIHdpbGwg YmUgcnVubmluZyBvbiB0aGUgdXNlciBkZXZpY2UuIFNlZSBTSU9QICg8YSBocmVmPSJodHRwczov L2lkZW50aXR5LmZvdW5kYXRpb24vZGlkLXNpb3AvIiByZWw9Im5vb3BlbmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZl cnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9Im1hcmdpbjowcHgiPmh0dHBz Oi8vaWRlbnRpdHkuZm91bmRhdGlvbi9kaWQtc2lvcC88L2E+KS48L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+SSBicm93c2VkIHRocm91Z2gg dGhlIHR3byBkcmFmdHMsIGkuZS4gOjwvcD4NCjx1bD4NCjxsaT5EZWNlbnRyYWxpemVkIElkZW50 aWZpZXJzIChESURzKSB2MS4wIENvcmUgYXJjaGl0ZWN0dXJlLCBkYXRhIG1vZGVsLCBhbmQgcmVw cmVzZW50YXRpb25zIFczQyBXb3JraW5nIERyYWZ0IDA4IE5vdmVtYmVyIDIwMjANCjwvbGk+PGxp PlNlbGYtSXNzdWVkIE9wZW5JRCBDb25uZWN0IFByb3ZpZGVyIERJRCBQcm9maWxlIHYwLjEuIERJ RiBXb3JraW5nIEdyb3VwIERyYWZ0PC9saT48L3VsPg0KPHA+QXQgbm8gcGxhY2Ugd2l0aGluIHRo ZXNlIHR3byBkb2N1bWVudHMsIGl0IGlzIHBvc3NpYmxlIHRvIGltYWdpbmUgdGhhdCAmcXVvdDt0 aGUgQVMgd2lsbCBiZSBydW5uaW5nIG9uIHRoZSB1c2VyIGRldmljZSZxdW90Oy48YnI+DQo8L3A+ DQo8cD5Gcm9tIHNlY3Rpb24gMyBvZiB0aGUgRElGIFdvcmtpbmcgR3JvdXAgRHJhZnQ6PC9wPg0K PHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O1VubGlrZSB0aGUgT0lEQyBB dXRob3JpemF0aW9uIENvZGUgRmxvdyBhcyBwZXIgW09JREMuQ29yZV0sIHRoZSBTSU9QIHdpbGwg bm90IHJldHVybiBhbiBhY2Nlc3MgdG9rZW4gdG8gdGhlIFJQJnF1b3Q7Ljxicj4NCjwvcD4NCjxw PkFuIElkZW50aXR5IFdhbGxldCBpcyBub3QgYW4gQVMuIDxicj4NCjwvcD4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6MTVweDsgYmFja2dyb3VuZC1jb2xvcjpyZ2Io MjU1LDI1NSwyNTUpIj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZTox NXB4OyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPjxicj4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlci1jb2xvcjpyZ2IoMjAwLDIwMCwyMDApOyBib3JkZXItbGVm dC13aWR0aDozcHg7IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4OyBt YXJnaW4tbGVmdDowLjhleDsgY29sb3I6cmdiKDEwMiwxMDIsMTAyKSI+DQo8ZGl2IGRpcj0ibHRy IiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6 MTJwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyB0ZXh0LWFsaWduOmxlZnQ7IGJhY2tncm91bmQtY29sb3I6 d2hpdGUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4 Ij5Sb2xlczombmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPi0mZ3Q7IGdyYW50 IGVuZHBvaW50IG9mIHRoZSBBUzogV2h5IGlzIHRoaXMgYSBwb3N0IHJlcXVlc3Q/IFRoaXMgZWxp bWluYXRlcyB0aGUgY2hhbmNlIG9mIGhhdmluZyB1c2VyIGRldmljZSBob3N0ZWQgQVMgKG5vIHNl cnZlcikuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjowcHgiPjxmb250IGNvbG9yPSJyZWQiPltGSV0gd2hhdCB3b3VsZCB5b3UgcHJvcG9z ZSBpbnN0ZWFkPzwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxmb250IGNv bG9yPSJyZWQiPldvdWxkIGFsc28gYmUgaW50ZXJlc3RlZCB0byB1bmRlcnN0YW5kIGJldHRlciB0 aGUgZGVwbG95bWVudCBtb2RlbCB3aGVuIHRoZXJlIGlzIG5vIHNlcnZlci4gVGhhdCdzIHNvbWV0 aGluZyB0aGF0IHdhcyBkaXNjdXNzZWQgc2V2ZXJhbCB0aW1lcyBidXQgSSdtIHN0aWxsIG1pc3Np bmcgdGhlIHVuZGVybHlpbmcgYXJjaGl0ZWN0dXJlIGFuZCB1c2UgY2FzZS48L2ZvbnQ+PC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6MTVweDsg YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4mbmJzcDtbRlBdIFNlZSBhYm92ZSAo U0lPUCkuIFRoZXJlIHdpbGwgYmUgYSBsb3Qgb2YgaWRlbnRpdHkgd2FsbGV0cyBvcGVyYXRlZCBv biBlbmQgdXNlciBkZXZpY2UuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxwPlNlZSB0aGUgYWJvdmUgY29tbWVudC4gUGxlYXNlLCBkbyBub3Qg Y29uZnVzZSBhbiBJZGVudGl0eSBXYWxsZXQgd2l0aCBhbiBBdXRoZW50aWNhdGlvbiBTZXJ2ZXIg KEFTKS48L3A+DQo8cD5EZW5pczxicj4NCjwvcD4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K PGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 MHB4OyBmb250LXNpemU6MTVweDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj48 YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItY29sb3I6cmdiKDIwMCwyMDAs MjAwKTsgYm9yZGVyLWxlZnQtd2lkdGg6M3B4OyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgcGFk ZGluZy1sZWZ0OjFleDsgbWFyZ2luLWxlZnQ6MC44ZXg7IGNvbG9yOnJnYigxMDIsMTAyLDEwMiki Pg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OjBweDsgZm9udC1zaXplOjEycHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNh LHNhbnMtc2VyaWYiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgdGV4dC1hbGlnbjpsZWZ0OyBi YWNrZ3JvdW5kLWNvbG9yOndoaXRlIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOjBweCI+LSZndDsgUmVzb3VyY2UgT3duZXIgKFJPKSA6IEF1dGhvcml6ZXMg dGhlIHJlcXVlc3Q/IERvZXMgaXQgYXV0aG9yaXplIHRoZSByZXF1ZXN0IG9yIHRoZSBhY2Nlc3Mg dG8gYSByZXNvdXJjZT88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOjBweCI+PGZvbnQgY29sb3I9InJlZCI+W0ZJXSB5ZXMsIHdlIHNob3Vs ZCBtYWtlIHRoZSB3b3JkaW5nIGNsZWFyZXI8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIiBz dHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6MTJw dDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46MHB4OyB0ZXh0LWFsaWduOmxlZnQ7IGJhY2tncm91bmQtY29sb3I6d2hp dGUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48 YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPk1pc3NpbmcgU2VjdGlvbiBJbnRl cmFjdGlvbnM6PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4tLSZndDsgVGhpcyBzZWN0 aW9uIHNoYWxsIGludHJvZHVjZSB0aGUgbm90aW9uIG9mIGludGVyYWN0aW9uIGJlZm9yZSB3ZSBz dGFydCBsaXN0aW5nIGludGVyYWN0aW9uIHR5cGVzLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48Zm9udCBjb2xvcj0icmVkIj5b RkldIHllcyZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJtYXJnaW46 MHB4OyBmb250LXNpemU6MTVweDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxMnB0OyBmb250LWZhbWlseTpDYWxp YnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7 IHRleHQtYWxpZ246bGVmdDsgYmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxicj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0ibWFyZ2luOjBw eCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6MTJwdDsgZm9udC1mYW1pbHk6 Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 MHB4OyB0ZXh0LWFsaWduOmxlZnQ7IGJhY2tncm91bmQtY29sb3I6d2hpdGUiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij5JbnRlcmFjdGlvbiBUeXBl czo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPi0tJmd0OyBJIHByZWZlciBhIGNsYXNz aWZpY2F0aW9uIHdpdGggUmVkaXJlY3QsIERlY291cGxlZCBhbmQgRW1iZWRkZWQgaXMuIEluIHRo ZSBkcmFmdCwgd2UgaGF2ZSBvbmUgcmVkaXJlY3QgYW5kIDIgZGVjb3VwbGUgaW50ZXJhY3Rpb25z IGFuZCBub3RoaW5nIGVsc2UuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxmb250IGNvbG9yPSJyZWQiPltGSV0gdGhpcyBzaG91 bGQgYmUgaGFuZGxlZCBhcyBhIHNwZWNpZmljIGRpc2N1c3Npb24gaXRlbS4gQXMgYSByZW1pbmRl ciwgaG93IHdvdWxkIHlvdSBkZWZpbmUgZW1iZWRkZWQ/PC9mb250PjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOjBweCI+PGZvbnQgY29sb3I9InJlZCI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48Zm9udCBjb2xv cj0icmVkIj5JbiBwcmFjdGljZSB0aGVyZSdzIGF0IGxlYXN0IHRoZXNlIG1vZGVzOjwvZm9udD48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxmb250IGNvbG9yPSJyZWQiPi0gcmVkaXJl Y3QgYW5kIHJlZGlyZWN0IGJhY2s8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4 Ij48Zm9udCBjb2xvcj0icmVkIj4tIHJlZGlyZWN0IHRvIGRpZmZlcmVudCBicm93c2VyIG9yIGRl dmljZTwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxmb250IGNvbG9yPSJy ZWQiPi0gdXNlciBjb2RlPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGZv bnQgY29sb3I9InJlZCI+LSBDSUJBPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6MTVweDsgYmFja2dyb3VuZC1jb2xv cjpyZ2IoMjU1LDI1NSwyNTUpIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPltGUF0gVGhpcyBj bGFzc2lmaWNhdGlvbiBpcyBsaW1pdGVkLjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46MHB4OyBmb250LXNpemU6MTVweDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUp Ij4NCjx1bD4NCjxsaT5SZWRpcmVjdDogc2FtZSBkZXZpY2UsIHNhbWUgb3IgZGlmZmVyZW50IHVz ZXIgYWdlbnRzIChicm93c2VyLCBtb2JpbGUgYXBwLCBkZXNrdG9wIGFwcCwgLi4uKTwvbGk+PGxp PkRlY291cGxlZDogZGlmZmVyZW50IGRldmljZXM8L2xpPjxsaT5FbWJlZGRlZCA6IFJDIGNhcnJp ZXMgUk8gYXV0aG9yaXphdGlvbiB0byBBUzwvbGk+PC91bD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOjBweDsgZm9udC1zaXplOjE1cHg7IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUs MjU1KSI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6MTJwdDsgZm9udC1mYW1pbHk6Q2FsaWJy aSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyB0 ZXh0LWFsaWduOmxlZnQ7IGJhY2tncm91bmQtY29sb3I6d2hpdGUiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1jb2xvcjpy Z2IoMjAwLDIwMCwyMDApOyBib3JkZXItbGVmdC13aWR0aDozcHg7IGJvcmRlci1sZWZ0LXN0eWxl OnNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4OyBtYXJnaW4tbGVmdDowLjhleDsgY29sb3I6cmdiKDEw MiwxMDIsMTAyKSI+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6MTJwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlh bCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyB0ZXh0LWFs aWduOmxlZnQ7IGJhY2tncm91bmQtY29sb3I6d2hpdGUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBw eCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij5SZXNvdXJjZSBBY2Nlc3MgUmVxdWVzdCB2cy4g UmVzb3VyY2UgUmVxdWVzdDwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+LS0mZ3Q7IEJv dGggYXJlIG1peGVkIHVwLiBObyBjbGFyaWZpY2F0aW9uIG9mIHRoZSBjb250ZXh0IG9mIGVhY2gg c2VjdGlvbi48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOjBweCI+PGZvbnQgY29sb3I9InJlZCI+W0ZJXSBjb3VsZCB5b3UgY2xhcmlmeSB3 aGF0IHlvdSdkIGV4cGVjdC4mbmJzcDsgQnR3IG9uIHRoaXMgdG9waWMsIHRoZXJlJ3MgYSBtb3Jl IGdlbmVyYWwgZGlzY3Vzc2lvbiBvbiB3aGV0aGVyIHdlIHNob3VsZCBtYWtlIGEgZGlzdGluY3Rp b24gb3Igbm90LiZuYnNwOzwvZm9udD48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgc3R5bGU9 Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxNXB4OyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1 LDI1NSkiPjxmb250IGNvbG9yPSJyZWQiPjxzcGFuIHN0eWxlPSJtYXJnaW46MHB4OyBjb2xvcjpy Z2IoMCwzNiw4MSkiPltGUF06IEhlcmU6PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxNXB4OyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1 LDI1NSkiPg0KPHVsPg0KPGxpPjxmb250IGNvbG9yPSJyZWQiPjxzcGFuIHN0eWxlPSJtYXJnaW46 MHB4OyBjb2xvcjpyZ2IoMCwzNiw4MSkiPjxzcGFuIHN0eWxlPSJtYXJnaW46MHB4OyBmb250LWZh bWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyB0ZXh0LWFsaWduOmxlZnQ7 IGJhY2tncm91bmQtY29sb3I6d2hpdGUiPlJlc291cmNlIEFjY2VzcyBSZXF1ZXN0OiBSZXF1ZXN0 aW5nIEFjY2VzcyB0byBhIHJlc291cmNlLiBSZXNwb25zZSBpcyBhbiBhY2Nlc3MNCiB0b2tlbiAo b3IgYW55IHR5cGUgb2YgZ3JhbnQpPC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9saT48bGk+PGZvbnQg Y29sb3I9InJlZCI+PHNwYW4gc3R5bGU9Im1hcmdpbjowcHg7IGNvbG9yOnJnYigwLDM2LDgxKSI+ PHNwYW4gc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0 aWNhLHNhbnMtc2VyaWY7IHRleHQtYWxpZ246bGVmdDsgYmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+ UmVzb3VyY2UgUmVxdWVzdDogUmVxdWVzdCB0aGUgcmVzb3VyY2UuIFJlc3BvbnNlIGlzIHRoZSBy ZXNvdXJjZSAob3IgYSBjb3JyZXNwb25kaW5nDQogZXhlY3V0aW9uKTwvc3Bhbj48L3NwYW4+PC9m b250PjwvbGk+PC91bD4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9Im1hcmdpbjowcHgi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1zaXplOjEycHQ7IGZvbnQtZmFtaWx5OkNh bGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBw eDsgdGV4dC1hbGlnbjpsZWZ0OyBiYWNrZ3JvdW5kLWNvbG9yOndoaXRlIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjowcHgiPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlci1jb2xvcjpyZ2IoMjAwLDIwMCwyMDApOyBib3JkZXItbGVmdC13 aWR0aDozcHg7IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4OyBtYXJn aW4tbGVmdDowLjhleDsgY29sb3I6cmdiKDEwMiwxMDIsMTAyKSI+DQo8ZGl2IGRpcj0ibHRyIiBz dHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6MTJw dDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46MHB4OyB0ZXh0LWFsaWduOmxlZnQ7IGJhY2tncm91bmQtY29sb3I6d2hp dGUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij5U b2tlbiBDb250ZW50IE5lZ290aWF0aW9uPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4t LSZndDsgTm90IGV4cHJlc3NlZCBhcyBzdWNoLiBUaGlzIGlzIGNlbnRyYWwgdG8gR05BUCBhbmQg bm90IHJlcHJlc2VudGVkIGVub3VnaCZuYnNwOyBpbiB0aGUgZG9jdW1lbnQuPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxmb250 IGNvbG9yPSJyZWQiPltGSV0gcmlnaHQuIFRoaXMgc2hvdWxkIGJlIGEgc3BlY2lmaWMgZGlzY3Vz c2lvbiBpdGVtLiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJtYXJn aW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxMnB0OyBmb250LWZh bWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjowcHg7IHRleHQtYWxpZ246bGVmdDsgYmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+UmVxdWVzdGluZyAmcXVvdDtVc2VyJnF1b3Q7IElu Zm9ybWF0aW9uPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij53ZSBpZGVudGlmeSB0d28g dHlwZXMgb2YgdXNlcnM6IFJRIGFuZCBSTy4gSXQgd2lsbCBiZSBiZXR0ZXIgbm90IHRvIHJlZmVy IHRvIGEgdXNlciBpbiB0aGlzIGRyYWZ0LCBidXQgZWl0aGVyIHRvIGEgUlEgb3IgYW4gUk8uPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjow cHgiPjxmb250IGNvbG9yPSJyZWQiPltGSV0geWVzIHRoYXQgd291bGQgYXZvaWQgcG90ZW50aWFs IG1pc3VuZGVyc3RhbmRpbmdzLiBBbHRob3VnaCBpbiB0aGUgZW5kLCBwZW9wbGUgd2lsbCB0cmFu c2xhdGUgUlEgaW50byB1c2VyJm5ic3A7b3IgZW5kLXVzZXIgbW9zdCBvZiB0aGUgdGltZS4gQ2Yg aW4gZGVmaW5pdGlvbiwgY3VycmVudGx5IHdlIGhhdmUmbmJzcDs8L2ZvbnQ+PHNwYW4+PGZvbnQg Y29sb3I9InJlZCI+UmVxdWVzdGluZw0KIFBhcnR5IChSUSwgYWthICZxdW90O3VzZXImcXVvdDsp PC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxicj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJtYXJnaW46 MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxMnB0OyBmb250LWZhbWls eTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjowcHg7IHRleHQtYWxpZ246bGVmdDsgYmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+SW50ZXJhY3Rpb24gQWdhaW48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+LSZndDsgRm9yIGVhY2gg aW50ZXJhY3Rpb24gdHlwZSwgd2Ugd2lsbCBoYXZlIHRvIGRlc2NyaWJlIHRoZSBwcm90b2NvbCBm bG93IGFuZCB0aGUgbmF0dXJlIGFuZCBiZWhhdmlvciBvZiBpbnZvbHZlZCBSb2xlcyAoUGFydGll cyksIEVsZW1lbnRzLCBSZXF1ZXN0cy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48Zm9udCBjb2xvcj0icmVkIj5b RkldIHllcyZuYnNwOyZuYnNwOzwvZm9udD48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgZGly PSJsdHIiIHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQt c2l6ZToxMnB0OyBmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlm Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IHRleHQtYWxpZ246bGVmdDsgYmFja2dyb3VuZC1j b2xvcjp3aGl0ZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdp bjowcHgiPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6MTVweDsgYmFja2dyb3VuZC1jb2xvcjpyZ2Io MjU1LDI1NSwyNTUpIj5bRlBdIFdpbGwgdGhlc2UgYW5kIGludG8gdGlja2V0cz88L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxNXB4OyBiYWNrZ3JvdW5kLWNvbG9yOnJn YigyNTUsMjU1LDI1NSkiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgZm9u dC1zaXplOjE1cHg7IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+QmVzdCByZWdh cmRzLjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1zaXplOjE1cHg7IGJhY2tn cm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+L0ZyYW5jaXM8L2Rpdj4NCjxicj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGZpZWxkc2V0PjwvZmllbGRzZXQ+IDwv YmxvY2txdW90ZT4NCjxwPjxicj4NCjwvcD4NCjwvZGl2Pg0KLS0gPGJyPg0KVFhBdXRoIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUWEF1dGhAaWV0Zi5vcmciIHJlbD0ibm9yZWZl cnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVy IG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBu b3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+VFhBdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoIiByZWw9Im5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZl cnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQotLSA8YnI+DQpUWEF1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRY QXV0aEBpZXRmLm9yZyIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZl cnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5UWEF1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90eGF1dGgiIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8L2E+PGJyPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQotLSA8YnI+ DQpUWEF1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRYQXV0aEBpZXRmLm9y ZyIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVm ZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVy cmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5UWEF1dGhAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 eGF1dGgiIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBu b3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9y ZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVm ZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aDwvYT48YnI+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCi0tIDxicj4NClRYQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86VFhBdXRoQGlldGYub3JnIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBu b3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9y ZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVm ZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0 PSJfYmxhbmsiPlRYQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVy IG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBu b3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9y ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHhhdXRoPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQotLSA8YnI+DQpUWEF1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOlRYQXV0aEBpZXRmLm9yZyIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIg bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPlRYQXV0aEBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0 aCIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVm ZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVy cmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dHhhdXRoPC9hPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KLS0g PGJyPg0KVFhBdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUWEF1dGhAaWV0 Zi5vcmciIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBu b3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9y ZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVm ZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5UWEF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHJlbD0ibm9yZWZl cnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVy IG5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhh dXRoPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQotLSA8YnI+DQpUWEF1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRY QXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+VFhBdXRoQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHhhdXRoIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxicj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_FR2P281MB0106C0A62253D04A1070873F8DB09FR2P281MB0106DEUP_-- From nobody Mon Feb 8 05:19:50 2021 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 6A3503A16D3 for ; Mon, 8 Feb 2021 05:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, PDS_SHORTFWD_URISHRT_QP=1.498, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 IyPy-882TXR1 for ; Mon, 8 Feb 2021 05:19:43 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3393A16D2 for ; Mon, 8 Feb 2021 05:19:42 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 118DJWGj012534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 Feb 2021 08:19:33 -0500 From: Justin Richer Message-Id: <7A612194-5C4B-4658-B7F0-E6058D044255@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_E8FBA7D2-844A-4952-9A0E-607A392A4C6B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 8 Feb 2021 08:19:32 -0500 In-Reply-To: Cc: Fabien Imbault , Adrian Gropper , Tom Jones , txauth gnap To: Francis Pouatcha References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 13:19:49 -0000 --Apple-Mail=_E8FBA7D2-844A-4952-9A0E-607A392A4C6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree that the focus of this group does need to be on an HTTP-based AS = =E2=80=94 this particular use case is the one that we have to solve for, = and that=E2=80=99s why those details are called out in the charter. We = aren=E2=80=99t here to try to build a transport-independent security = language, with abstractions and bindings and things of that sort. But = that said, the =E2=80=9Con-device AS=E2=80=9D use case is being brought = up a lot, and solutions have been hacked together in the OAuth 2 world = in several different ways. As such, we as a WG should be paying = attention to them, and if there are things we can do in our design to = allow for that kind of deployment then we need to consider them. That = doesn=E2=80=99t mean we have to have that fully specified in the core = protocol, but if there=E2=80=99s a way to design this so that it can be = extended in that direction without the kind of hacks that the OAuth 2 = solutions have to rely on, then it=E2=80=99ll be better for everyone. = This can=E2=80=99t distract us from solving the core use cases, or drive = us to making the core so complex that it becomes irrelevant, but we = shouldn=E2=80=99t be blind to these other possibilities. In my opinion as a contributor, the best opportunities we have for that = kind of extension in the way the protocol=E2=80=99s built right now are = in the interaction and continuation pieces of GNAP. Interaction we=E2=80=99= ve always known was going to allow for a move off-browser, and less = dependence on user-in-a-browser is baked into the charter as well. But = we need more experience and more details about :how: that works, and = that=E2=80=99s a lot of what this current conversation is going to be = about. You are completely right that there are another set of = challenges, but in my mind it=E2=80=99s that the trust model is simply = different. What do I trust more, a device in my pocket or a web server = in someone else=E2=80=99s data center? There isn=E2=80=99t an easy or = universal answer to that question, as it turns out. =E2=80=94 Justin > On Feb 7, 2021, at 5:51 PM, Francis Pouatcha wrote: >=20 > Hello Fabian, >=20 > I am sorry for the delayed reply, but very busy working on those = decentralized use cases where tokens a produced on the user device. >=20 >=20 > Like we can see in this thread, it is not obvious to have those use = cases considered in GNAP (as the GNAP charter mentions reliance on HTTP = based AS). >=20 > If the role of an AS is to produce an authorization, a user device = hosted AS can be build, but the negotiation process will be different = from the one defined by GNAP. Means interaction protocol will need more = than just HTTP. >=20 > The biggest challenge we are facing on user device produced auth = tokens is on how to preserve those crypto keys held on user device from = malware, loss of device... >=20 > For the moment keeping focus of GNAP on (http) server-based production = of token looks like a good decision. >=20 > I will review the draft sometime as soon as possible and provide my = feedback. >=20 > Best regards, >=20 > /Francis >=20 > From: TXAuth on behalf of Fabien Imbault = > Sent: Friday, February 5, 2021 3:41 PM > To: Adrian Gropper > Cc: Tom Jones ; txauth gnap = ; Justin Richer > Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > =20 > Hi Adrian, >=20 > We would be glad to get your expertise on that. Not sure DIDComm is = essential yet, so far I see it personally as something to look into, = especially for use cases when we want to reach out to a RO. I agree with = the potential issues.=20 >=20 > I have a few ideas on how to implement privacy, but it's quite = involved in terms of crypto (again using Ristretto groups :-)). >=20 > Of course there will be a question of priority in the features we plan = to implement. I guess we should aim for a first publication without the = parts which are blurry, and take the time to prototype the rest.=20 >=20 > Cheers > Fabien=20 >=20 > Le ven. 5 f=C3=A9vr. 2021 =C3=A0 21:19, Adrian Gropper = > a =C3=A9crit : > There are privacy implications as well as the cost of processing spam. = A service endpoint associated with a DID can be presumed to be a public = broadcast. Any party can attempt to send a message or an authorization = request to that service endpoint. The operator of that service, = typically the DID controller, will bear the cost and risk of processing = the message. They may request a bond be posted by the party responding = to the "broadcast" in order to mitigate spam and phishing. They may also = require that the party seeking to communicate offer credentials, which = poses a privacy risk to that party in the form of phishing "broadcasts" = via DIDs and lures that lead to DIDs.=20 >=20 > In my role as invited expert on privacy to some W3C WGs and, to some = extent, DIF WGs, I have not managed to understand the privacy = engineering and implications in DIDcomm. I will try harder if DIDcomm = has an essential role with GNAP and I can understand it in the = self-sovereign or fiduciary authorization server context. Does it? >=20 > Adrian >=20 > On Fri, Feb 5, 2021 at 1:08 PM Fabien Imbault = > wrote: > Probably (and to be honest even for industrial users I find it = complex), but alternatives are not ready for prime time either.=20 > Maybe some day DIDComm could be useful as a basic block, what we = suggest is to first use that as a potential interaction (and there's = already a lot of questions that arise just from that).=20 >=20 > Fabien >=20 > On Fri, Feb 5, 2021 at 6:55 PM Tom Jones > wrote: > No, you didn't misunderstand me. It's just that the ux for that is not = acceptable to retail users. As long as gnap sticks to industrial users = you should do fine. >=20 > thx ..Tom (mobile) >=20 > On Fri, Feb 5, 2021, 7:56 AM Fabien Imbault > wrote: > Targeting existing browsers and types of applications (web, pwa, = mobile, etc.) seems like a reasonable option for an industrial standard. = Improving security, privacy, ease of use and interoperability (including = decentralized identity as well) should be good enough objectives.=20 > Plus from our previous discussions, I was under the impression you = were fine with the approach of deploying the AS on the phone as a = loopback, for mobile apps. Did I miss something? >=20 > Cheers, > Fabien >=20 > Le ven. 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones = > a = =C3=A9crit : > If you mean can GNAP work on old fashioned apps running with existing = browsers and existing identity providers, then yes, i guess you are ok. >=20 > If you want to work on apps where the user is in control of authn and = authz, then no, GNAP cannot work. It is not alone in that OIDC wont work = there either. >=20 > Be the change you want to see in the world > ..tom >=20 >=20 > On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault = > wrote: > Hi Tom,=20 >=20 > Thanks, your responses made it clearer for me what you expect from an = AS deployed on a mobile.=20 >=20 > I think we're on the right path to meet the rest of your concerns. = There are already a few items on these: > - privacy preserving techniques have been discussed and are likely to = be included (I think). It's been recognized as a core concern=20 > - not exactly sure the meaning you give to discovery here (it's = already been used in the WG but with a different meaning I believe). The = request or the continuation api provide entry points to pay attention = to.=20 >=20 > Is that enough for your use case ? Do you need something else ? (like = SSE?) >=20 > Cheers > Fabien=20 >=20 > Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom Jones = > a = =C3=A9crit : > discovery is the prime problem. What causes the wallet/AS to wake up = and pay attention. How does the RP know what to ask for without = violating user privacy rights? >=20 > CHAPI would be ok i guess, but that requires cred man to be fixed. Not = sure if it fixes discovery or privacy even then. >=20 > Be the change you want to see in the world > ..tom >=20 >=20 > On Thu, Feb 4, 2021 at 12:45 PM Justin Richer > wrote: > Tom, what additional functionality do you see that a browser would = need to support in order for GNAP to be adopted? For the elements of the = core protocol today, nothing is needed to change within the browsers =E2=80= =94 everything is built on existing functions. GNAP uses browsers as a = tool, and I would argue depends on them even less so than OAuth 2 does. = Extensions could use browser functionality, like using CHAPI to pass = interaction elements, but the core protocol functions on vanilla = browsers today. >=20 > =E2=80=94 Justin >=20 >> On Feb 4, 2021, at 3:20 PM, Tom Jones > wrote: >>=20 >> i assumed that the wallet (aka AS) needed to be a native app, not a = PWA (which can come from a traditional web server). >> There are folks, lke Kim C, who are working on a PWA, but i agree the = blocks there seem to be large. >> THe blocks on a native app are simple, easy to describe, and easy to = ask the browser guys to fix. Not sure if they care tho. >> I have trouble seeing a path to GNAP adoption for retail customers = w/o some browser support. >> That's why i am mostly silent here. >>=20 >> Be the change you want to see in the world >> ..tom >>=20 >>=20 >> On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault = > wrote: >> Fair enough. But loopback limits a lot what you can do... Just for = debug it's a pain.=20 >> But as soon as you try more, it's a bit crazy. Fun to test ipv6 = (luckily supported by my ISP) and ddns. But it feels really hacky.=20 >> Also deployment is a pain, compared to a traditional webserver.=20 >>=20 >> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones = > a = =C3=A9crit : >> doesn't work very well on windows uwp. works fine on smartphones >> Be the change you want to see in the world >> ..tom >>=20 >>=20 >> On Thu, Feb 4, 2021 at 11:18 AM Justin Richer > wrote: >> OK, thanks =E2=80=94 in that case, there are no changes at all to = GNAP, which is already HTTP driven. The harder parts tend to be where = you can=E2=80=99t (or don=E2=80=99t want to) use something like that. >>=20 >> =E2=80=94 Justin >>=20 >>> On Feb 4, 2021, at 2:16 PM, Tom Jones > wrote: >>>=20 >>> yes, loopback >>>=20 >>> Be the change you want to see in the world >>> ..tom >>>=20 >>>=20 >>> On Thu, Feb 4, 2021 at 11:01 AM Justin Richer > wrote: >>> Tom, can you expand on how exactly the back-channel communication = works between on-device components? Do you use HTTP locally? >>>=20 >>> Thanks, >>> =E2=80=94 Justin >>>=20 >>>> On Feb 4, 2021, at 1:03 PM, Tom Jones > wrote: >>>>=20 >>>> Justin's analysis of use of the front channel is misleading. >>>> It could equally be argued that what i have done is installed an AS = on the phone and the communications with it & the PR is back channel. >>>> Basically the point is that the old OIDC paradigms are no longer = valid. >>>> Be the change you want to see in the world >>>> ..tom >>>>=20 >>>>=20 >>>> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault = > wrote: >>>> Yes, issue (#168) message based interaction / DIDComm is a = tentative alternative mecanism for the interaction part. Not sure how = that would work in details though, prototyping will probably help here. >>>> Token delivery through continuation seems fine to me. The client = will probably have to wait for the next polling before it receives a = token issued as the result of an asynchronous interaction, but that's = not a big issue. >>>>=20 >>>> But the AS on the phone seems like a harder nut to crack, at least = at first sight. I think that would be awesome, but it gives me = headaches, so I think I'll work on easier stuff right now ;-) >>>>=20 >>>> Fabien =20 >>>>=20 >>>> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer > wrote: >>>> One of the biggest drawbacks of the current app-centric approaches = in OIDC (self-issued OP, or SIOP) is that they depend on using the front = channel and browser redirects to pass everything, which is something = that GNAP is deliberately getting away from by starting in the back = channel. >>>>=20 >>>> That said, once a request is kicked off in GNAP, the interaction = and fulfillment can happen through any number of means. Part of the work = that=E2=80=99s being done with the =E2=80=9Cinteraction=E2=80=9D section = is going to help facilitate this, and I think that there are some other = potential branches here. >>>>=20 >>>> Token delivery is where things get extra weird though =E2=80=94 we = are explicitly not delivering tokens in the front channel in the core of = GNAP, we=E2=80=99re using the response from the continuation API. One = idea (that isn=E2=80=99t particularly well thought out and hasn=E2=80=99t = been implemented at all) is to have an extension declare an alternative = response from the =E2=80=9Ccontinue=E2=80=9D section that=E2=80=99s = defined today, which points to the GNPA continuation API. If an = extension defines some alternative way to deliver tokens, that could = live alongside a continuation API and the client could indicate support = for it in its initial request. >>>>=20 >>>> In any event, alternative interaction and delivery methods are = important, and even if we aren=E2=80=99t going to support every last one = of them directly, the protocol design should at least be aware of them. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault = > wrote: >>>>>=20 >>>>> Hi Tom,=20 >>>>>=20 >>>>> Sure, any experience on that would be greatly appreciated, we're = calling for help here (the point being that I suspect what they're doing = is not trivial). >>>>>=20 >>>>> Fabien >>>>>=20 >>>>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones = > = wrote: >>>>> I've had such an app working for over a year. There are issues = which are being addressed by the browser Interaction team of oidc. >>>>>=20 >>>>> thx ..Tom (mobile) >>>>>=20 >>>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault = > wrote: >>>>> Hi Francis,=20 >>>>>=20 >>>>> I've tried a few things with regards to using the AS on a phone, = but it's really quite complex.=20 >>>>>=20 >>>>> Making that run on a phone comes with quite a bit of trouble. The = most difficult part if that we'd need to use a secure element, but just = installing and hosting a http server securely is not a standard setup at = all. I suggest interested people step in to work on this, as we already = have a lot of work for the (more usual) server case and already handle a = privacy preserving scheme.=20 >>>>>=20 >>>>> Please let us know what you think. >>>>>=20 >>>>> Cheers, >>>>> Fabien=20 >>>>>=20 >>>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault = > wrote: >>>>> Hi Francis, >>>>>=20 >>>>> I've thought a bit more to what you said. I think I'll give it a = try as a separate experiment (in code, not in theory). Not that I would = expect it to be included in GNAP, but I kind of like the idea :-) >>>>>=20 >>>>> The direct impact for GNAP would be to think about multiple ASs.=20= >>>>>=20 >>>>> Will let you know.=20 >>>>>=20 >>>>> Fabien=20 >>>>>=20 >>>>>=20 >>>>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha = > a =C3=A9crit : >>>>> It would be nice if the protocol was designed at many layers of = abstraction. >>>>>=20 >>>>> The first layer shall design abstract protocol flows, without = specification of the mode and mechanism of interaction. >>>>> The second layer can instantiate the first layer for dedicated = interaction. Here we can talk http, we can define interactions that = presume server based token generation, we can define interaction that = run on user device based token generation. >>>>> This is also the fundament of the structure I proposed for the = spec (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30 = ). >>>>>=20 >>>>> /Francis >>>>>=20 >>>>> From: Fabien Imbault > >>>>> Sent: Wednesday, November 18, 2020 6:35 AM >>>>> To: Francis Pouatcha > >>>>> Cc: txauth@ietf.org >; Dick Hardt >; Tom Jones >; Denis >; Justin Richer > >>>>> Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>> =20 >>>>> Would make sense, but not so easy as we rely heavily on HTTP. = Hence the discussion about deep links and so on. >>>>>=20 >>>>> An alternative might be provided by wasm/wasi (running a local = sandbox on your phone, for your own AS), but it's really early stage. = This also poses another question that Denis has put forward, i.e. how do = we handle the multiple AS scenario (likely to occur then).=20 >>>>>=20 >>>>> Fabien=20 >>>>>=20 >>>>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha > wrote: >>>>> We are drifting away from the original problem space. >>>>> My original mention was about the "POST" request, that subsumes = that the "AS" is a "Server". Designing a new protocol, we cannot afford = this limitation. >>>>> I just mentioned SIOP to show a known and closed example? Let us = not focus on the device local discovery scheme (like openid:) for now. >>>>> As capability of holding private keys on user device evolves, = server-based issuing of token will be fading out giving way to device = local generation of token. >>>>> While designing GNAP, let us assume the AS-Role can be exercised = on a user device and design the protocol to honor that. >>>>>=20 >>>>> Best regards, >>>>> /Francis >>>>> From: TXAuth > on behalf of Dick Hardt = > >>>>> Sent: Tuesday, November 17, 2020 1:28 PM >>>>> To: Tom Jones > >>>>> Cc: Fabien Imbault >; Denis >; GNAP Mailing List >; Justin Richer > >>>>> Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>>>> =20 >>>>> Got it.=20 >>>>>=20 >>>>> So web apps invoke a openid: deep link and hope there is an app to = handle the openid: scheme? ... and that it is the user's wallet rather = than some malware that has registered openid: on the mobile device? >>>>>=20 >>>>> A native app can attempt to open a deep link associated with an = app, and will fail if the app is not there. If the app is there, it will = be opened, so this can't be used to silently test if an app is present, = but it does allow a native app to provide an alternative experience if = an app is not present. I don't think this works with custom schemes ... = and I don't know how it could work from a web app on the phone with the = current Safari APIs. >>>>>=20 >>>>> Apple warns against using custom schemes [1] ... but perhaps they = can be convinced to make openid: a managed scheme similar to mailto:, = tel:, sms:, facetime: ? >>>>>=20 >>>>> [1] = https://developer.apple.com/documentation/xcode/allowing_apps_and_websites= _to_link_to_your_content/defining_a_custom_url_scheme_for_your_app = >>>>>=20 >>>>>=20 >>>>> =E1=90=A7 >>>>>=20 >>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones = > = wrote: >>>>> You are - that is not standard which is opeind:// >>>>> This is the one step that still needs to be optimized for SIOP to = have good UX. >>>>> Peace ..tom >>>>>=20 >>>>>=20 >>>>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt > wrote: >>>>> Hi Tom >>>>>=20 >>>>> I watched your video (I watched at 2X speed) >>>>>=20 >>>>> Looks like the employment website app that is using localhost:8765 = to communicate with the wallet. Am I correct? >>>>>=20 >>>>> /Dick=20 >>>>> =E1=90=A7 >>>>>=20 >>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones = > = wrote: >>>>> Well, here's a demo. Note that in this case the AS is not online = all of the time, so it is really implicit flow and the OIDC id-token = comes from the siop device directly. >>>>> (whether this is front-channel or back channel is no longer an = interesting question.) >>>>> Now if an always-on AS is required, that is possible, but probably = beyond the scope of this effort and would require something like an = agent-in-the-sky (with diamonds). >>>>> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 = >>>>> Peace ..tom >>>>>=20 >>>>>=20 >>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer > wrote: >>>>> Ultimately, in most situations like these in the real world, the = hurdle isn=E2=80=99t technical compatibility so much as it is trust = compatibility. The RP (client) needs to have some incentive to trust the = assertions and identity information that=E2=80=99s coming from the AS. = The same is true for an RS trusting tokens from the AS. The hard = question is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), = but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t = answer very well, because it=E2=80=99s a hard question). >>>>>=20 >>>>> Still: it=E2=80=99s definitely a question about how to support = this =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start = of it more than OAuth2/OIDC have by allowing the bootstrap of the = process from a starting call: the interaction and continuation URIs = handed back by the AS don=E2=80=99t need to be the same URIs that the = client starts with, so just like SIOP the process can start in HTTP and = potentially move to other communication channels. A major difference is = that we aren=E2=80=99t dependent on the assumption that the user will = always be in a browser at some stage, and so the whole raft of = front-channel messages that SIOP relies on doesn=E2=80=99t fly. That = said, we=E2=80=99ve got an opportunity to more explicitly open up = alternative communication channels here, and that=E2=80=99s something = I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. = I=E2=80=99d love to see a concrete proposal as to how that would work = over specific protocols, starting with what we=E2=80=99ve got today.=20 >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault = > wrote: >>>>>>=20 >>>>>> Hi Denis, hi Francis,=20 >>>>>>=20 >>>>>> At some point integration with SSI (on the authentication side) = will probably occur, including amongst other possibilities SIOP (since = they work with OpenID a part of the work will probably be made easier).=20= >>>>>>=20 >>>>>> That being said, Denis is right. It's not an AS. Technically it's = entirely possible to rely on a decentralized wallet (for instance on = your phone) and a centralized AS. I know of a few studies on how to = decentralize the AS itself (for instance = https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02 = ). >>>>>> Maybe it exists, but I'm still looking for real scenarios (or = even architectures) where an AS is deployed directly on a phone, and = under the sole authority of the RO, while being compatible with the rest = of the world.=20 >>>>>>=20 >>>>>> Cheers, >>>>>> Fabien >>>>>>=20 >>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis > wrote: >>>>>> Hello Francis, >>>>>>=20 >>>>>> See two comments in line. >>>>>>=20 >>>>>>>=20 >>>>>>> B) Current Document >>>>>>>=20 >>>>>>> Roles description shall not hold any assumption on the physical = structure of the party fulfilling the roles. >>>>>>> [FI] not sure what you mean >>>>>>> [FP] for example, we assume the AS is a server! In most SSI = based use cases, the AS will be running on the user device. See SIOP = (https://identity.foundation/did-siop/ = ). >>>>>> I browsed through the two drafts, i.e. : >>>>>> Decentralized Identifiers (DIDs) v1.0 Core architecture, data = model, and representations W3C Working Draft 08 November 2020 >>>>>> Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft >>>>>> At no place within these two documents, it is possible to imagine = that "the AS will be running on the user device". >>>>>> =46rom section 3 of the DIF Working Group Draft: >>>>>> "Unlike the OIDC Authorization Code Flow as per = [OIDC.Core], the SIOP will not return an access token to the RP". >>>>>> An Identity Wallet is not an AS.=20 >>>>>>>=20 >>>>>>> Roles:=20 >>>>>>> -> grant endpoint of the AS: Why is this a post request? This = eliminates the chance of having user device hosted AS (no server). >>>>>>> [FI] what would you propose instead? >>>>>>> Would also be interested to understand better the deployment = model when there is no server. That's something that was discussed = several times but I'm still missing the underlying architecture and use = case. >>>>>>> [FP] See above (SIOP). There will be a lot of identity wallets = operated on end user device. >>>>>> See the above comment. Please, do not confuse an Identity Wallet = with an Authentication Server (AS). >>>>>> Denis >>>>>>>=20 >>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it = authorize the request or the access to a resource? >>>>>>> [FI] yes, we should make the wording clearer >>>>>>>=20 >>>>>>> Missing Section Interactions: >>>>>>> --> This section shall introduce the notion of interaction = before we start listing interaction types. >>>>>>> [FI] yes=20 >>>>>>>=20 >>>>>>> Interaction Types: >>>>>>> --> I prefer a classification with Redirect, Decoupled and = Embedded is. In the draft, we have one redirect and 2 decouple = interactions and nothing else. >>>>>>> [FI] this should be handled as a specific discussion item. As a = reminder, how would you define embedded? >>>>>>>=20 >>>>>>> In practice there's at least these modes: >>>>>>> - redirect and redirect back >>>>>>> - redirect to different browser or device >>>>>>> - user code >>>>>>> - CIBA >>>>>>> [FP] This classification is limited. >>>>>>> Redirect: same device, same or different user agents (browser, = mobile app, desktop app, ...) >>>>>>> Decoupled: different devices >>>>>>> Embedded : RC carries RO authorization to AS >>>>>>>=20 >>>>>>>=20 >>>>>>> Resource Access Request vs. Resource Request >>>>>>> --> Both are mixed up. No clarification of the context of each = section. >>>>>>> [FI] could you clarify what you'd expect. Btw on this topic, = there's a more general discussion on whether we should make a = distinction or not.=20 >>>>>>> [FP]: Here: >>>>>>> Resource Access Request: Requesting Access to a resource. = Response is an access token (or any type of grant) >>>>>>> Resource Request: Request the resource. Response is the resource = (or a corresponding execution) >>>>>>>=20 >>>>>>> Token Content Negotiation >>>>>>> --> Not expressed as such. This is central to GNAP and not = represented enough in the document. >>>>>>> [FI] right. This should be a specific discussion item.=20 >>>>>>>=20 >>>>>>> Requesting "User" Information >>>>>>> we identify two types of users: RQ and RO. It will be better not = to refer to a user in this draft, but either to a RQ or an RO. >>>>>>> [FI] yes that would avoid potential misunderstandings. Although = in the end, people will translate RQ into user or end-user most of the = time. Cf in definition, currently we have Requesting Party (RQ, aka = "user") >>>>>>>=20 >>>>>>>=20 >>>>>>> Interaction Again >>>>>>> -> For each interaction type, we will have to describe the = protocol flow and the nature and behavior of involved Roles (Parties), = Elements, Requests. >>>>>>> [FI] yes =20 >>>>>>>=20 >>>>>>> [FP] Will these and into tickets? >>>>>>>=20 >>>>>>> Best regards. >>>>>>> /Francis >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>>> --=20 >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>>=20 >>>>> --=20 >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>> --=20 >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>=20 >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_E8FBA7D2-844A-4952-9A0E-607A392A4C6B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree that the focus of this group does need to be on an HTTP-based AS = =E2=80=94 this particular use case is the one that we have to solve for, = and that=E2=80=99s why those details are called out in the charter. We = aren=E2=80=99t here to try to build a transport-independent security = language, with abstractions and bindings and things of that sort. But = that said, the =E2=80=9Con-device AS=E2=80=9D use case is being brought = up a lot, and solutions have been hacked together in the OAuth 2 world = in several different ways. As such, we as a WG should be paying = attention to them, and if there are things we can do in our design to = allow for that kind of deployment then we need to consider them. That = doesn=E2=80=99t mean we have to have that fully specified in the core = protocol, but if there=E2=80=99s a way to design this so that it can be = extended in that direction without the kind of hacks that the OAuth 2 = solutions have to rely on, then it=E2=80=99ll be better for everyone. = This can=E2=80=99t distract us from solving the core use cases, or drive = us to making the core so complex that it becomes irrelevant, but we = shouldn=E2=80=99t be blind to these other possibilities.

In my opinion as a = contributor, the best opportunities we have for that kind of extension = in the way the protocol=E2=80=99s built right now are in the interaction = and continuation pieces of GNAP. Interaction we=E2=80=99ve always known = was going to allow for a move off-browser, and less dependence on = user-in-a-browser is baked into the charter as well. But we need more = experience and more details about :how: that works, and that=E2=80=99s a = lot of what this current conversation is going to be about. You are = completely right that there are another set of challenges, but in my = mind it=E2=80=99s that the trust model is simply different. What do I = trust more, a device in my pocket or a web server in someone else=E2=80=99= s data center? There isn=E2=80=99t an easy or universal answer to that = question, as it turns out.

 =E2=80=94 Justin

On Feb 7, 2021, at 5:51 PM, Francis Pouatcha <fpo@adorsys.de> = wrote:

Hello = Fabian,

I am sorry for the delayed = reply, but very busy working on those decentralized use cases where = tokens a produced on the user device.


Like we can see in this thread, it is not obvious to = have those use cases considered in GNAP (as the GNAP charter mentions = reliance on HTTP based AS).

If = the role of an AS is to produce an authorization, a user device hosted = AS can be build, but the negotiation process will be different from the = one defined by GNAP. Means interaction protocol will need more than just = HTTP.

The biggest challenge we are = facing on user device produced auth tokens is on how to preserve those = crypto keys held on user device from malware, loss of = device...

For the moment keeping focus of = GNAP on (http) server-based production of token looks like a good = decision.

I will review the draft = sometime as soon as possible and provide my feedback.

Best regards,

/Francis

From: TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imbault = <fabien.imbault@gmail.com>
Sent: Friday, February 5, 2021 = 3:41 PM
To: Adrian Gropper <agropper@healthurl.com>
Cc: Tom = Jones <thomasclinganjones@gmail.com>; txauth gnap <txauth@ietf.org>; = Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of = draft-ietf-gnap-core-protocol-00
 
Hi = Adrian,

We would be glad to get your expertise on that. Not sure = DIDComm is essential yet, so far I see it personally as something to = look into, especially for use cases when we want to reach out to a RO. I = agree with the potential issues. 

I have a = few ideas on how to implement privacy, but it's quite involved in terms = of crypto (again using Ristretto groups :-)).

Of course = there will be a question of priority in the features we plan to = implement. I guess we should aim for a first publication without the = parts which are blurry, and take the time to prototype the = rest. 

Cheers
Fabien 

Le ven. = 5 f=C3=A9vr. 2021 =C3=A0 21:19, Adrian Gropper <agropper@healthurl.com> a =C3=A9crit :
There are privacy implications as well as the = cost of processing spam. A service endpoint associated with a DID can be = presumed to be a public broadcast. Any party can attempt to send a = message or an authorization request to that service endpoint. The = operator of that service, typically the DID controller, will bear the = cost and risk of processing the message. They may request a bond be = posted by the party responding to the "broadcast" in order to mitigate = spam and phishing. They may also require that the party seeking to = communicate offer credentials, which poses a privacy risk to that party = in the form of phishing "broadcasts" via DIDs and lures that lead to = DIDs. 

In my = role as invited expert on privacy to some W3C WGs and, to some extent, = DIF WGs, I have not managed to understand the privacy engineering and = implications in DIDcomm. I will try harder if DIDcomm has an essential = role with GNAP and I can understand it in the self-sovereign or = fiduciary authorization server context. Does it?

Adrian

On Fri, = Feb 5, 2021 at 1:08 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Probably (and to be honest even for industrial = users I find it complex), but alternatives are not ready for prime time = either. 
Maybe some day DIDComm could be useful = as a basic block, what we suggest is to first use that as a potential = interaction (and there's already a lot of questions that arise just from = that). 

Fabien

On Fri, = Feb 5, 2021 at 6:55 PM Tom Jones <thomasclinganjones@gmail.com> = wrote:
No, you didn't = misunderstand me. It's just that the ux for that is not acceptable to = retail users. As long as gnap sticks to industrial users you should do = fine.

thx ..Tom = (mobile)

On Fri, Feb 5, 2021, 7:56 AM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
Targeting existing browsers and types of applications (web, = pwa, mobile, etc.) seems like a reasonable option for an industrial = standard. Improving security, privacy, ease of use and interoperability = (including decentralized identity as well) should be good enough = objectives. 
Plus from our previous = discussions, I was under the impression you were fine with the approach = of deploying the AS on the phone as a loopback, for mobile apps. Did I = miss something?

Cheers,
Fabien

Le ven. 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones = <thomasclinganjones@gmail.com> a =C3=A9crit :
If you mean can GNAP work on old = fashioned apps running with existing browsers and existing identity = providers, then yes, i guess you are ok.

If you want to work on apps where the = user is in control of authn and authz, then no, GNAP cannot work. It is = not alone in that OIDC wont work there either.

Be the change you want to see in the = world ..tom


On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
Hi Tom, 

Thanks, your responses = made it clearer for me what you expect from an AS deployed on a = mobile. 

I think we're on the right path to meet the rest = of your concerns. There are already a few items on these:
- privacy preserving techniques have been = discussed and are likely to be included (I think). It's been recognized = as a core concern 
- not exactly = sure the meaning you give to discovery here (it's already been used in = the WG but with a different meaning I believe). The request or the = continuation api provide entry points to pay attention = to. 

Is that enough for your use case ? Do you need something else = ? (like SSE?)

Cheers
Fabien 

Le jeu. 4 f=C3=A9vr. = 2021 =C3=A0 22:10, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit :
discovery is the prime problem.  What causes = the wallet/AS to wake up and pay attention. How does the RP know what to = ask for without violating user privacy rights?

CHAPI would be ok i guess, but that = requires cred man to be fixed. Not sure if it fixes discovery or privacy = even then.

Be the change you = want to see in the world ..tom


On Thu, Feb 4, 2021 at 12:45 PM Justin Richer = <jricher@mit.edu> wrote:
Tom, what = additional functionality do you see that a browser would need to support = in order for GNAP to be adopted? For the elements of the core protocol = today, nothing is needed to change within the browsers =E2=80=94 = everything is built on existing functions. GNAP uses browsers as a tool, = and I would argue depends on them even less so than OAuth 2 does. = Extensions could use browser functionality, like using CHAPI to pass = interaction elements, but the core protocol functions on vanilla = browsers today.

 =E2=80=94 Justin

On Feb = 4, 2021, at 3:20 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

i assumed that = the wallet (aka AS) needed to be a native app, not a PWA (which can come = from a traditional web server).
There are folks, lke Kim = C, who are working on a PWA, but i agree the blocks there seem to be = large.
THe blocks on a native app are simple, easy = to describe, and easy to ask the browser guys to fix. Not sure if they = care tho.
I have trouble seeing a path to GNAP = adoption for retail customers w/o some browser support.
That's why i am mostly silent here.

Be the change you want to see in the = world ..tom


On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
Fair enough. But loopback limits a lot what you = can do... Just for debug it's a pain. 
But as soon as you try more, it's a bit crazy. Fun to test = ipv6 (luckily supported by my ISP) and ddns. But it feels really = hacky. 
Also deployment is a = pain, compared to a traditional webserver. 

Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones = <thomasclinganjones@gmail.com> a =C3=A9crit :
doesn't work very well on windows uwp. works fine = on smartphones
Be the change you = want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:18 AM Justin Richer = <jricher@mit.edu> = wrote:
OK, thanks =E2=80=94 in that case, = there are no changes at all to GNAP, which is already HTTP driven. The = harder parts tend to be where you can=E2=80=99t (or don=E2=80=99t want = to) use something like that.

 =E2=80=94 Justin

On Feb = 4, 2021, at 2:16 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

yes, loopback

Be the = change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:01 AM Justin Richer = <jricher@mit.edu> = wrote:
Tom, can you expand on how exactly = the back-channel  communication works between on-device components? = Do you use HTTP locally?

Thanks,
 =E2=80=94 Justin

On Feb 4, 2021, at 1:03 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

Justin's analysis = of use of the front channel is misleading.
It could = equally be argued that what i have done is installed an AS on the phone = and the communications with it & the PR is back channel.
Basically the point is that the old OIDC paradigms are no = longer valid.
Be the change you want to see in the = world ..tom


On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
Yes, issue (#168) message based interaction = / DIDComm is a tentative alternative mecanism for the interaction part. = Not sure how that would work in details though, prototyping will = probably help here.
Token delivery through = continuation seems fine to me. The client will probably have to wait for = the next polling before it receives a token issued as the result of an = asynchronous interaction, but that's not a big issue.

But the AS on the phone = seems like a harder nut to crack, at least at first sight. I think that = would be awesome, but it gives me headaches, so I think I'll work on = easier stuff right now ;-)

Fabien  

On Thu, Feb 4, 2021 at 4:30 PM Justin Richer = <jricher@mit.edu> = wrote:
One of the biggest drawbacks of the = current app-centric approaches in OIDC (self-issued OP, or SIOP) is that = they depend on using the front channel and browser redirects to pass = everything, which is something that GNAP is deliberately getting away = from by starting in the back channel.

That said, once a request is kicked off = in GNAP, the interaction and fulfillment can happen through any number = of means. Part of the work that=E2=80=99s being done with the = =E2=80=9Cinteraction=E2=80=9D section is going to help facilitate this, = and I think that there are some other potential branches here.

Token delivery is where = things get extra weird though =E2=80=94 we are explicitly not delivering = tokens in the front channel in the core of GNAP, we=E2=80=99re using the = response from the continuation API. One idea (that isn=E2=80=99t = particularly well thought out and hasn=E2=80=99t been implemented at = all) is to have an extension declare an alternative response from the = =E2=80=9Ccontinue=E2=80=9D section that=E2=80=99s defined today, which = points to the GNPA continuation API. If an extension defines some = alternative way to deliver tokens, that could live alongside a = continuation API and the client could indicate support for it in its = initial request.

In any event, alternative interaction and delivery methods = are important, and even if we aren=E2=80=99t going to support every last = one of them directly, the protocol design should at least be aware of = them.

 =E2=80= =94 Justin

On Feb 4, 2021, at 8:35 AM, = Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Tom, 

Sure, any experience on = that would be greatly appreciated, we're calling for help here (the = point being that I suspect what they're doing is not trivial).

Fabien

On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
I've had such an app working for over a year. = There are issues which are being addressed by the browser Interaction = team of oidc.

thx ..Tom = (mobile)

On Thu, Feb 4, 2021, 3:12 AM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis, 

I've tried a few things with regards to = using the AS on a phone, but it's really = quite complex. 

Making that run on a phone comes with quite a bit of trouble. = The most difficult part if that we'd need to use a secure element, but = just installing and hosting a http server securely is not a standard = setup at all. I suggest interested people step in to work on this, as we = already have a lot of work for the (more usual) server case and already = handle a privacy preserving scheme. 

Please let us know what you = think.

Cheers,
Fabien 

On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
Hi Francis,

I've = thought a bit more to what you said. I think I'll give it a try as a = separate experiment (in code, not in theory). Not that I would expect it = to be included in GNAP, but I kind of like the idea :-)

The direct impact for GNAP would be to think about multiple = ASs. 

Will let you know. 

Fabien 


Le mer. = 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha <fpo@adorsys.de> a = =C3=A9crit :
It = would be nice if the protocol was designed at many layers of = abstraction.

  • The first layer shall = design abstract protocol flows, without specification of the mode and = mechanism of interaction.
  • The second layer can = instantiate the first layer for dedicated interaction. Here we can talk = http, we can define interactions that presume server based token = generation, we can define interaction that run on user device based = token generation.
This is also the fundament of = the structure I proposed for the spec (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, = 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>; Dick Hardt <dick.hardt@gmail.com>; Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of = draft-ietf-gnap-core-protocol-00
 
Would make sense, but not so easy as we rely heavily on HTTP. = Hence the discussion about deep links and so on.

An alternative might be provided by = wasm/wasi (running a local sandbox on your phone, for your own AS), but = it's really early stage. This also poses another question that Denis has = put forward, i.e. how do we handle the multiple AS scenario (likely to = occur then). 

Fabien 

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha = <fpo@adorsys.de> wrote:
We = are drifting away from the original problem space.
  • My original mention was = about the "POST" request, that subsumes that the "AS" is a "Server". = Designing a new protocol, we cannot afford this limitation.
  • I just mentioned SIOP to show a known and closed example? Let = us not focus on the device local discovery scheme (like openid:) for = now.
  • As capability of holding private keys on user = device evolves, server-based issuing of token will be fading out giving = way to device local generation of token.
While = designing GNAP, let us assume the AS-Role can be exercised on a user = device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-bounces@ietf.org> on behalf of Dick Hardt = <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 = 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@free.fr>; GNAP Mailing List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of = draft-ietf-gnap-core-protocol-00
 
Got it. 

So web apps invoke a openid: deep link = and hope there is an app to handle the openid: scheme? ... and that it = is the user's wallet rather than some malware that has registered = openid: on the mobile device?

A native app can attempt to open a deep = link associated with an app, and will fail if the app is not there. If = the app is there, it will be opened, so this can't be used to silently = test if an app is present, but it does allow a native app to provide an = alternative experience if an app is not present. I don't think this = works with custom schemes ... and I don't know how it could work from a = web app on the phone with the current Safari APIs.

Apple warns against = using custom schemes [1] ... but perhaps they can be convinced to make = openid: a managed scheme similar to mailto:, tel:, sms:, facetime: = ?

[1] https://developer.apple.com/documentation/xcode/allowing_apps_a= nd_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_= app


3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is = opeind://
This is the one step that still needs to = be optimized for SIOP to have good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom

I = watched your video (I watched at 2X speed)

Looks like the employment website app = that is using localhost:8765 to communicate with the wallet. Am I = correct?

/Dick 
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is not = online all of the time, so it is really implicit flow and the OIDC = id-token comes from the siop device directly.
(whether = this is front-channel or back channel is no longer an interesting = question.)
Now if an always-on AS is = required, that is possible, but probably beyond the scope of this effort = and would require something like an agent-in-the-sky (with = diamonds).
here is the link to the 9 min = video   https://youtu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer = <jricher@mit.edu> wrote:
Ultimately, in most = situations like these in the real world, the hurdle isn=E2=80=99t = technical compatibility so much as it is trust compatibility. The RP = (client) needs to have some incentive to trust the assertions and = identity information that=E2=80=99s coming from the AS. The same is true = for an RS trusting tokens from the AS. The hard question is less = =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but more =E2=80=9Cwh= y=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very well, = because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a = question about how to support this =E2=80=9CAS on device=E2=80=9D = element. We=E2=80=99ve got the start of it more than OAuth2/OIDC have by = allowing the bootstrap of the process from a starting call: the = interaction and continuation URIs handed back by the AS don=E2=80=99t = need to be the same URIs that the client starts with, so just like SIOP = the process can start in HTTP and potentially move to other = communication channels. A major difference is that we aren=E2=80=99t = dependent on the assumption that the user will always be in a browser at = some stage, and so the whole raft of front-channel messages that SIOP = relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got an = opportunity to more explicitly open up alternative communication = channels here, and that=E2=80=99s something I=E2=80=99d like to see = engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a = concrete proposal as to how that would work over specific protocols, = starting with what we=E2=80=99ve got today. 
 =E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault = <fabien.imbault@gmail.com> wrote:

Hi Denis, hi = Francis, 

At = some point integration with SSI (on the authentication side) will = probably occur, including amongst other possibilities SIOP (since they = work with OpenID a part of the work will probably be made = easier). 

That being said, Denis is right. It's not an AS. Technically = it's entirely possible to rely on a decentralized wallet (for instance = on your phone) and a centralized AS. I know of a few studies on how to = decentralize the AS itself (for instance https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-= 02).
Maybe it exists, but I'm still looking for = real scenarios (or even architectures) where an AS is deployed directly = on a phone, and under the sole authority of the RO, while being = compatible with the rest of the world. 

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
Hello  Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any = assumption on the physical structure of the party fulfilling the = roles.
[FI] not sure what you = mean
 [FP] for example, we assume the AS is a server! = In most SSI based use cases, the AS will be running on the user device. = See SIOP (https://identity.foundation/did-siop/).
I browsed through the two drafts, i.e. :
  • Decentralized Identifiers (DIDs) v1.0 Core = architecture, data model, and representations W3C Working Draft 08 = November 2020
  • Self-Issued OpenID Connect Provider DID = Profile v0.1. DIF Working Group Draft
At no place within these two = documents, it is possible to imagine that "the AS will be running on the = user device".
=46rom section 3 of the DIF Working = Group Draft:
      "Unlike the OIDC Authorization = Code Flow as per [OIDC.Core], the SIOP will not return an access token = to the RP".
An Identity Wallet is not an AS. 

Roles: 
-> grant endpoint of the AS: Why is = this a post request? This eliminates the chance of having user device = hosted AS (no server).
[FI] what would you = propose instead?
Would also be interested to understand better = the deployment model when there is no server. That's something that was = discussed several times but I'm still missing the underlying = architecture and use case.
 [FP] See above (SIOP). There will be a lot of identity = wallets operated on end user = device.
See the above = comment. Please, do not confuse an Identity Wallet with an = Authentication Server (AS).
Denis

-> Resource Owner = (RO) : Authorizes the request? Does it authorize the request or the = access to a resource?
[FI] yes, we should make = the wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of = interaction before we start listing interaction = types.
[FI] = yes 

Interaction Types:
--> I prefer a classification with Redirect, Decoupled and = Embedded is. In the draft, we have one redirect and 2 decouple = interactions and nothing else.
[FI] = this should be handled as a specific discussion item. As a reminder, how = would you define embedded?

In practice there's at least = these modes:
- redirect and redirect back
- = redirect to different browser or device
- user = code
- CIBA
[FP] This = classification is limited.
  • Redirect: same device, same or different user = agents (browser, mobile app, desktop app, ...)
  • Decoupled: different devices
  • Embedded : RC = carries RO authorization to AS


Resource Access Request vs. Resource Request
--> Both are mixed up. No = clarification of the context of each = section.
[FI] could you clarify what = you'd expect.  Btw on this topic, there's a more general discussion = on whether we should make a distinction or = not. 
[FP]: Here:
  • Resource Access Request: Requesting Access to a resource. = Response is an access token (or any type of = grant)
  • Resource Request: Request the resource. Response is the = resource (or a corresponding = execution)

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not = represented enough  in the = document.
[FI] right. This should be a = specific discussion item. 

Requesting "User" Information
we identify two types of users: RQ and RO. It will be = better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid = potential misunderstandings. Although in the end, people will translate = RQ into user or end-user most of the time. Cf in definition, = currently we have Requesting Party (RQ, aka "user")


Interaction Again
-> For each = interaction type, we will have to describe the protocol flow and the = nature and behavior of involved Roles (Parties), Elements, = Requests.
[FI] = yes  

[FP] Will these and into tickets?

Best = regards.
/Francis



-- 
TXAuth = mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
-- 
TXAuth = mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

-- 
TXAuth = mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
-- 
TXAuth = mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

-- 
TXAuth = mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


-- 
TXAuth = mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
<= /blockquote>= -- 
TXAuth = mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
= --Apple-Mail=_E8FBA7D2-844A-4952-9A0E-607A392A4C6B-- From nobody Mon Feb 8 05:22:08 2021 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 6C3513A16D7 for ; Mon, 8 Feb 2021 05:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 nmWIuNl9mkNI for ; Mon, 8 Feb 2021 05:22:01 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 9AE263A16D5 for ; Mon, 8 Feb 2021 05:22:01 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id r21so5624972otk.13 for ; Mon, 08 Feb 2021 05:22:01 -0800 (PST) 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=vTz5j2GQsn8HNdIhElzLol4e+ZKE/46NlwpYnhdzOTw=; b=oYnK5jDW8DPfQm4YHgjtZZo+4MBv4i34ZTU2Kg+OlNpdjrlh4I/kE3U3GKveZCzSVV 8GUbWjvGbUuXYgWECwveiOHzByScj+NN8KH8ip3o7nlvoCZoIgRcNEn3YnAYaaEvmvUE 97xVaWggSSrzddxNR1YcSrx8SkkkGO/vXCFn9W2CHjGFavlWGsNvWbgN2SDBH4KjLtrr i4G0e3AcuslXIldazuBfDGBbzOSUnVZ5yPoKYRcEAuFHKi1cXbKPe8A+dXIlYV+xHjeT YiZ+Y3XpNlh8DyuKT7Wi7Q/Tw6jxdUDenuAsGZ0Qr+xQvYQduAIIn+ovMhwMY2K13aBt OQbA== 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=vTz5j2GQsn8HNdIhElzLol4e+ZKE/46NlwpYnhdzOTw=; b=QGIFIsPfEBsyoGvFy2vy1xWnwLg6jEMsUj6UwteZsuPyEpmv8sUZAi1WYBnRtk57jq vzFXnZ53+jMYVhbrkLqqZ1YlJGnYCOVWVZINUFp4f5znau38nr0LTk6I4UgUjc8iDABI lzzukFuynSUN/yMBDwZZgASrJd+vaJW0OG51ez7J711RoBv7hjok7BLY1YZdZDS7IiK2 ZuAsyNrPh5MxsggiBHVqwXqp8xN3XzIInVU4qcwNH8ir2G4KtW2EQLdWyRPat3oOyhay dijmQ6NVXQtDbFHM0e2nt0ecn4lKjvSf/mFI4puFtCdvEiHCO7Kj6L3vAlipWY8vNR57 Rv7w== X-Gm-Message-State: AOAM5327UgMFQ9VzsR1Ja5sL+5/LO+4r0S7YIoBP927rKnIu+7h6u/xU KCl7+63wWdjqXxOW25mpQQAUeuSX+YwyUEZfWMQ= X-Google-Smtp-Source: ABdhPJzY1/8OBB8xf8oDVC6686/rVXcRcK1j499eOgIpEvRUtezbSC9PR4z+1kzUI9qva3+sSiJNe+ES7eCyyscSVuc= X-Received: by 2002:a9d:37c4:: with SMTP id x62mr12956062otb.87.1612790520527; Mon, 08 Feb 2021 05:22:00 -0800 (PST) MIME-Version: 1.0 References: <7A612194-5C4B-4658-B7F0-E6058D044255@mit.edu> In-Reply-To: <7A612194-5C4B-4658-B7F0-E6058D044255@mit.edu> From: Tom Jones Date: Mon, 8 Feb 2021 05:21:47 -0800 Message-ID: To: Justin Richer Cc: Francis Pouatcha , Fabien Imbault , Adrian Gropper , txauth gnap Content-Type: multipart/alternative; boundary="00000000000012bfb905bad30ea9" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 13:22:07 -0000 --00000000000012bfb905bad30ea9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin +1 thx ..Tom (mobile) On Mon, Feb 8, 2021, 5:19 AM Justin Richer wrote: > I agree that the focus of this group does need to be on an HTTP-based AS = =E2=80=94 > this particular use case is the one that we have to solve for, and that= =E2=80=99s > why those details are called out in the charter. We aren=E2=80=99t here t= o try to > build a transport-independent security language, with abstractions and > bindings and things of that sort. But that said, the =E2=80=9Con-device A= S=E2=80=9D use > case is being brought up a lot, and solutions have been hacked together i= n > the OAuth 2 world in several different ways. As such, we as a WG should b= e > paying attention to them, and if there are things we can do in our design > to allow for that kind of deployment then we need to consider them. That > doesn=E2=80=99t mean we have to have that fully specified in the core pro= tocol, but > if there=E2=80=99s a way to design this so that it can be extended in tha= t > direction without the kind of hacks that the OAuth 2 solutions have to re= ly > on, then it=E2=80=99ll be better for everyone. This can=E2=80=99t distrac= t us from solving > the core use cases, or drive us to making the core so complex that it > becomes irrelevant, but we shouldn=E2=80=99t be blind to these other poss= ibilities. > > In my opinion as a contributor, the best opportunities we have for that > kind of extension in the way the protocol=E2=80=99s built right now are i= n the > interaction and continuation pieces of GNAP. Interaction we=E2=80=99ve al= ways known > was going to allow for a move off-browser, and less dependence on > user-in-a-browser is baked into the charter as well. But we need more > experience and more details about :how: that works, and that=E2=80=99s a = lot of > what this current conversation is going to be about. You are completely > right that there are another set of challenges, but in my mind it=E2=80= =99s that > the trust model is simply different. What do I trust more, a device in my > pocket or a web server in someone else=E2=80=99s data center? There isn= =E2=80=99t an easy > or universal answer to that question, as it turns out. > > =E2=80=94 Justin > > On Feb 7, 2021, at 5:51 PM, Francis Pouatcha wrote: > > Hello Fabian, > > I am sorry for the delayed reply, but very busy working on those > decentralized use cases where tokens a produced on the user device. > > > Like we can see in this thread, it is not obvious to have those use cases > considered in GNAP (as the GNAP charter mentions reliance on HTTP based A= S). > > If the role of an AS is to produce an authorization, a user device hosted > AS can be build, but the negotiation process will be different from the o= ne > defined by GNAP. Means interaction protocol will need more than just HTTP= . > > The biggest challenge we are facing on user device produced auth tokens i= s > on how to preserve those crypto keys held on user device from malware, lo= ss > of device... > > For the moment keeping focus of GNAP on (http) server-based production of > token looks like a good decision. > > I will review the draft sometime as soon as possible and provide my > feedback. > > Best regards, > > /Francis > > ------------------------------ > *From:* TXAuth on behalf of Fabien Imbault < > fabien.imbault@gmail.com> > *Sent:* Friday, February 5, 2021 3:41 PM > *To:* Adrian Gropper > *Cc:* Tom Jones ; txauth gnap < > txauth@ietf.org>; Justin Richer > *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > > Hi Adrian, > > We would be glad to get your expertise on that. Not sure DIDComm is > essential yet, so far I see it personally as something to look into, > especially for use cases when we want to reach out to a RO. I agree with > the potential issues. > > I have a few ideas on how to implement privacy, but it's quite involved i= n > terms of crypto (again using Ristretto groups :-)). > > Of course there will be a question of priority in the features we plan to > implement. I guess we should aim for a first publication without the part= s > which are blurry, and take the time to prototype the rest. > > Cheers > Fabien > > Le ven. 5 f=C3=A9vr. 2021 =C3=A0 21:19, Adrian Gropper a > =C3=A9crit : > > There are privacy implications as well as the cost of processing spam. A > service endpoint associated with a DID can be presumed to be a public > broadcast. Any party can attempt to send a message or an authorization > request to that service endpoint. The operator of that service, typically > the DID controller, will bear the cost and risk of processing the message= . > They may request a bond be posted by the party responding to the > "broadcast" in order to mitigate spam and phishing. They may also require > that the party seeking to communicate offer credentials, which poses a > privacy risk to that party in the form of phishing "broadcasts" via DIDs > and lures that lead to DIDs. > > In my role as invited expert on privacy to some W3C WGs and, to some > extent, DIF WGs, I have not managed to understand the privacy engineering > and implications in DIDcomm. I will try harder if DIDcomm has an essentia= l > role with GNAP and I can understand it in the self-sovereign or fiduciary > authorization server context. Does it? > > Adrian > > On Fri, Feb 5, 2021 at 1:08 PM Fabien Imbault > wrote: > > Probably (and to be honest even for industrial users I find it complex), > but alternatives are not ready for prime time either. > Maybe some day DIDComm could be useful as a basic block, what we suggest > is to first use that as a potential interaction (and there's already a lo= t > of questions that arise just from that). > > Fabien > > On Fri, Feb 5, 2021 at 6:55 PM Tom Jones > wrote: > > No, you didn't misunderstand me. It's just that the ux for that is not > acceptable to retail users. As long as gnap sticks to industrial users yo= u > should do fine. > > thx ..Tom (mobile) > > On Fri, Feb 5, 2021, 7:56 AM Fabien Imbault > wrote: > > Targeting existing browsers and types of applications (web, pwa, mobile, > etc.) seems like a reasonable option for an industrial standard. Improvin= g > security, privacy, ease of use and interoperability (including > decentralized identity as well) should be good enough objectives. > Plus from our previous discussions, I was under the impression you were > fine with the approach of deploying the AS on the phone as a loopback, fo= r > mobile apps. Did I miss something? > > Cheers, > Fabien > > Le ven. 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones a > =C3=A9crit : > > If you mean can GNAP work on old fashioned apps running with existing > browsers and existing identity providers, then yes, i guess you are ok. > > If you want to work on apps where the user is in control of authn and > authz, then no, GNAP cannot work. It is not alone in that OIDC wont work > there either. > > Be the change you want to see in the world ..tom > > > On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault > wrote: > > Hi Tom, > > Thanks, your responses made it clearer for me what you expect from an AS > deployed on a mobile. > > I think we're on the right path to meet the rest of your concerns. There > are already a few items on these: > - privacy preserving techniques have been discussed and are likely to be > included (I think). It's been recognized as a core concern > - not exactly sure the meaning you give to discovery here (it's already > been used in the WG but with a different meaning I believe). The request = or > the continuation api provide entry points to pay attention to. > > Is that enough for your use case ? Do you need something else ? (like SSE= ?) > > Cheers > Fabien > > Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom Jones a > =C3=A9crit : > > discovery is the prime problem. What causes the wallet/AS to wake up and > pay attention. How does the RP know what to ask for without violating use= r > privacy rights? > > CHAPI would be ok i guess, but that requires cred man to be fixed. Not > sure if it fixes discovery or privacy even then. > > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 12:45 PM Justin Richer wrote: > > Tom, what additional functionality do you see that a browser would need t= o > support in order for GNAP to be adopted? For the elements of the core > protocol today, nothing is needed to change within the browsers =E2=80=94 > everything is built on existing functions. GNAP uses browsers as a tool, > and I would argue depends on them even less so than OAuth 2 does. > Extensions could use browser functionality, like using CHAPI to pass > interaction elements, but the core protocol functions on vanilla browsers > today. > > =E2=80=94 Justin > > On Feb 4, 2021, at 3:20 PM, Tom Jones > wrote: > > i assumed that the wallet (aka AS) needed to be a native app, not a PWA > (which can come from a traditional web server). > There are folks, lke Kim C, who are working on a PWA, but i agree the > blocks there seem to be large. > THe blocks on a native app are simple, easy to describe, and easy to ask > the browser guys to fix. Not sure if they care tho. > I have trouble seeing a path to GNAP adoption for retail customers w/o > some browser support. > That's why i am mostly silent here. > > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault > wrote: > > Fair enough. But loopback limits a lot what you can do... Just for debug > it's a pain. > But as soon as you try more, it's a bit crazy. Fun to test ipv6 (luckily > supported by my ISP) and ddns. But it feels really hacky. > Also deployment is a pain, compared to a traditional webserver. > > Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones a > =C3=A9crit : > > doesn't work very well on windows uwp. works fine on smartphones > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 11:18 AM Justin Richer wrote: > > OK, thanks =E2=80=94 in that case, there are no changes at all to GNAP, w= hich is > already HTTP driven. The harder parts tend to be where you can=E2=80=99t = (or don=E2=80=99t > want to) use something like that. > > =E2=80=94 Justin > > On Feb 4, 2021, at 2:16 PM, Tom Jones > wrote: > > yes, loopback > > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 11:01 AM Justin Richer wrote: > > Tom, can you expand on how exactly the back-channel communication works > between on-device components? Do you use HTTP locally? > > Thanks, > =E2=80=94 Justin > > On Feb 4, 2021, at 1:03 PM, Tom Jones > wrote: > > Justin's analysis of use of the front channel is misleading. > It could equally be argued that what i have done is installed an AS on th= e > phone and the communications with it & the PR is back channel. > Basically the point is that the old OIDC paradigms are no longer valid. > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault > wrote: > > Yes, issue (#168) message based interaction / DIDComm is a tentative > alternative mecanism for the interaction part. Not sure how that would wo= rk > in details though, prototyping will probably help here. > Token delivery through continuation seems fine to me. The client will > probably have to wait for the next polling before it receives a token > issued as the result of an asynchronous interaction, but that's not a big > issue. > > But the AS on the phone seems like a harder nut to crack, at least at > first sight. I think that would be awesome, but it gives me headaches, so= I > think I'll work on easier stuff right now ;-) > > Fabien > > On Thu, Feb 4, 2021 at 4:30 PM Justin Richer wrote: > > One of the biggest drawbacks of the current app-centric approaches in OID= C > (self-issued OP, or SIOP) is that they depend on using the front channel > and browser redirects to pass everything, which is something that GNAP is > deliberately getting away from by starting in the back channel. > > That said, once a request is kicked off in GNAP, the interaction and > fulfillment can happen through any number of means. Part of the work that= =E2=80=99s > being done with the =E2=80=9Cinteraction=E2=80=9D section is going to hel= p facilitate this, > and I think that there are some other potential branches here. > > Token delivery is where things get extra weird though =E2=80=94 we are ex= plicitly > not delivering tokens in the front channel in the core of GNAP, we=E2=80= =99re using > the response from the continuation API. One idea (that isn=E2=80=99t part= icularly > well thought out and hasn=E2=80=99t been implemented at all) is to have a= n > extension declare an alternative response from the =E2=80=9Ccontinue=E2= =80=9D section > that=E2=80=99s defined today, which points to the GNPA continuation API. = If an > extension defines some alternative way to deliver tokens, that could live > alongside a continuation API and the client could indicate support for it > in its initial request. > > In any event, alternative interaction and delivery methods are important, > and even if we aren=E2=80=99t going to support every last one of them dir= ectly, the > protocol design should at least be aware of them. > > =E2=80=94 Justin > > On Feb 4, 2021, at 8:35 AM, Fabien Imbault > wrote: > > Hi Tom, > > Sure, any experience on that would be greatly appreciated, we're calling > for help here (the point being that I suspect what they're doing is not > trivial). > > Fabien > > On Thu, Feb 4, 2021 at 2:21 PM Tom Jones > wrote: > > I've had such an app working for over a year. There are issues which are > being addressed by the browser Interaction team of oidc. > > thx ..Tom (mobile) > > On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault > wrote: > > Hi Francis, > > I've tried a few things with regards to using the AS on a phone, but it's > really quite complex. > > Making that run on a phone comes with quite a bit of trouble. The most > difficult part if that we'd need to use a secure element, but just > installing and hosting a http server securely is not a standard setup at > all. I suggest interested people step in to work on this, as we already > have a lot of work for the (more usual) server case and already handle a > privacy preserving scheme. > > Please let us know what you think. > > Cheers, > Fabien > > On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault > wrote: > > Hi Francis, > > I've thought a bit more to what you said. I think I'll give it a try as a > separate experiment (in code, not in theory). Not that I would expect it = to > be included in GNAP, but I kind of like the idea :-) > > The direct impact for GNAP would be to think about multiple ASs. > > Will let you know. > > Fabien > > > Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha a = =C3=A9crit : > > It would be nice if the protocol was designed at many layers of > abstraction. > > > - The first layer shall design abstract protocol flows, without > specification of the mode and mechanism of interaction. > - The second layer can instantiate the first layer for dedicated > interaction. Here we can talk http, we can define interactions that pr= esume > server based token generation, we can define interaction that run on u= ser > device based token generation. > > This is also the fundament of the structure I proposed for the spec ( > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). > > /Francis > > ------------------------------ > *From:* Fabien Imbault > *Sent:* Wednesday, November 18, 2020 6:35 AM > *To:* Francis Pouatcha > *Cc:* txauth@ietf.org ; Dick Hardt ; > Tom Jones ; Denis ; > Justin Richer > *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > > Would make sense, but not so easy as we rely heavily on HTTP. Hence the > discussion about deep links and so on. > > An alternative might be provided by wasm/wasi (running a local sandbox on > your phone, for your own AS), but it's really early stage. This also pose= s > another question that Denis has put forward, i.e. how do we handle the > multiple AS scenario (likely to occur then). > > Fabien > > On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha wrote: > > We are drifting away from the original problem space. > > - My original mention was about the "POST" request, that subsumes that > the "AS" is a "Server". Designing a new protocol, we cannot afford thi= s > limitation. > - I just mentioned SIOP to show a known and closed example? Let us not > focus on the device local discovery scheme (like openid:) for now. > - As capability of holding private keys on user device evolves, > server-based issuing of token will be fading out giving way to device = local > generation of token. > > While designing GNAP, let us assume the AS-Role can be exercised on a use= r > device and design the protocol to honor that. > > Best regards, > /Francis > ------------------------------ > *From:* TXAuth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Sent:* Tuesday, November 17, 2020 1:28 PM > *To:* Tom Jones > *Cc:* Fabien Imbault ; Denis ; > GNAP Mailing List ; Justin Richer > *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > > Got it. > > So web apps invoke a openid: deep link and hope there is an app to handle > the openid: scheme? ... and that it is the user's wallet rather than some > malware that has registered openid: on the mobile device? > > A native app can attempt to open a deep link associated with an app, and > will fail if the app is not there. If the app is there, it will be opened= , > so this can't be used to silently test if an app is present, but it does > allow a native app to provide an alternative experience if an app is not > present. I don't think this works with custom schemes ... and I don't kno= w > how it could work from a web app on the phone with the current Safari API= s. > > Apple warns against using custom schemes [1] ... but perhaps they can be > convinced to make openid: a managed scheme similar to mailto:, tel:, > sms:, facetime: ? > > [1] > https://developer.apple.com/documentation/xcode/allowing_apps_and_website= s_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app > > > =E1=90=A7 > > On Tue, Nov 17, 2020 at 10:06 AM Tom Jones > wrote: > > You are - that is not standard which is opeind:// > This is the one step that still needs to be optimized for SIOP to have > good UX. > Peace ..tom > > > On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt wrote: > > Hi Tom > > I watched your video (I watched at 2X speed) > > Looks like the employment website app that is using localhost:8765 to > communicate with the wallet. Am I correct? > > /Dick > =E1=90=A7 > > On Tue, Nov 17, 2020 at 9:46 AM Tom Jones > wrote: > > Well, here's a demo. Note that in this case the AS is not online all of > the time, so it is really implicit flow and the OIDC id-token comes from > the siop device directly. > (whether this is front-channel or back channel is no longer an interestin= g > question.) > Now if an always-on AS is required, that is possible, but probably beyond > the scope of this effort and would require something like an > agent-in-the-sky (with diamonds). > here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 > > Peace ..tom > > > On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: > > Ultimately, in most situations like these in the real world, the hurdle > isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP > (client) needs to have some incentive to trust the assertions and identit= y > information that=E2=80=99s coming from the AS. The same is true for an RS= trusting > tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to do= that (which SSI > answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, > because it=E2=80=99s a hard question). > > Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on device=E2=80=9D > element. We=E2=80=99ve got the start of it more than OAuth2/OIDC have by = allowing > the bootstrap of the process from a starting call: the interaction and > continuation URIs handed back by the AS don=E2=80=99t need to be the same= URIs that > the client starts with, so just like SIOP the process can start in HTTP a= nd > potentially move to other communication channels. A major difference is > that we aren=E2=80=99t dependent on the assumption that the user will alw= ays be in > a browser at some stage, and so the whole raft of front-channel messages > that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got an = opportunity to > more explicitly open up alternative communication channels here, and that= =E2=80=99s > something I=E2=80=99d like to see engineered, even if it=E2=80=99s an ext= ension. I=E2=80=99d love > to see a concrete proposal as to how that would work over specific > protocols, starting with what we=E2=80=99ve got today. > > =E2=80=94 Justin > > On Nov 17, 2020, at 12:03 PM, Fabien Imbault > wrote: > > Hi Denis, hi Francis, > > At some point integration with SSI (on the authentication side) will > probably occur, including amongst other possibilities SIOP (since they wo= rk > with OpenID a part of the work will probably be made easier). > > That being said, Denis is right. It's not an AS. Technically it's entirel= y > possible to rely on a decentralized wallet (for instance on your phone) a= nd > a centralized AS. I know of a few studies on how to decentralize the AS > itself (for instance > https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). > Maybe it exists, but I'm still looking for real scenarios (or even > architectures) where an AS is deployed directly on a phone, and under the > sole authority of the RO, while being compatible with the rest of the > world. > > Cheers, > Fabien > > On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: > > Hello Francis, > > See two comments in line. > > > B) Current Document > > Roles description shall not hold any assumption on the physical structure > of the party fulfilling the roles. > [FI] not sure what you mean > > [FP] for example, we assume the AS is a server! In most SSI based use > cases, the AS will be running on the user device. See SIOP ( > https://identity.foundation/did-siop/). > > I browsed through the two drafts, i.e. : > > - Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, > and representations W3C Working Draft 08 November 2020 > - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working > Group Draft > > At no place within these two documents, it is possible to imagine that > "the AS will be running on the user device". > From section 3 of the DIF Working Group Draft: > "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the > SIOP will not return an access token to the RP". > An Identity Wallet is not an AS. > > > Roles: > -> grant endpoint of the AS: Why is this a post request? This eliminates > the chance of having user device hosted AS (no server). > [FI] what would you propose instead? > Would also be interested to understand better the deployment model when > there is no server. That's something that was discussed several times but > I'm still missing the underlying architecture and use case. > > [FP] See above (SIOP). There will be a lot of identity wallets operated > on end user device. > > See the above comment. Please, do not confuse an Identity Wallet with an > Authentication Server (AS). > Denis > > > -> Resource Owner (RO) : Authorizes the request? Does it authorize the > request or the access to a resource? > [FI] yes, we should make the wording clearer > > Missing Section Interactions: > --> This section shall introduce the notion of interaction before we star= t > listing interaction types. > [FI] yes > > Interaction Types: > --> I prefer a classification with Redirect, Decoupled and Embedded is. I= n > the draft, we have one redirect and 2 decouple interactions and nothing > else. > [FI] this should be handled as a specific discussion item. As a reminder, > how would you define embedded? > > In practice there's at least these modes: > - redirect and redirect back > - redirect to different browser or device > - user code > - CIBA > > [FP] This classification is limited. > > - Redirect: same device, same or different user agents (browser, > mobile app, desktop app, ...) > - Decoupled: different devices > - Embedded : RC carries RO authorization to AS > > > > Resource Access Request vs. Resource Request > --> Both are mixed up. No clarification of the context of each section. > [FI] could you clarify what you'd expect. Btw on this topic, there's a > more general discussion on whether we should make a distinction or not. > > [FP]: Here: > > - Resource Access Request: Requesting Access to a resource. Response > is an access token (or any type of grant) > - Resource Request: Request the resource. Response is the resource (or > a corresponding execution) > > > Token Content Negotiation > --> Not expressed as such. This is central to GNAP and not represented > enough in the document. > [FI] right. This should be a specific discussion item. > > Requesting "User" Information > we identify two types of users: RQ and RO. It will be better not to refer > to a user in this draft, but either to a RQ or an RO. > [FI] yes that would avoid potential misunderstandings. Although in the > end, people will translate RQ into user or end-user most of the time. Cf = in > definition, currently we have Requesting Party (RQ, aka "user") > > > Interaction Again > -> For each interaction type, we will have to describe the protocol flow > and the nature and behavior of involved Roles (Parties), Elements, Reques= ts. > [FI] yes > > > [FP] Will these and into tickets? > > Best regards. > /Francis > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --00000000000012bfb905bad30ea9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Justin +1

= thx ..Tom (mobile)

On Mon, Feb 8, 2021, 5:19 AM Justin Richer <jricher@mit.edu> wrote:
I agree that the focus of this group does need to be on an= HTTP-based AS =E2=80=94 this particular use case is the one that we have t= o solve for, and that=E2=80=99s why those details are called out in the cha= rter. We aren=E2=80=99t here to try to build a transport-independent securi= ty language, with abstractions and bindings and things of that sort. But th= at said, the =E2=80=9Con-device AS=E2=80=9D use case is being brought up a = lot, and solutions have been hacked together in the OAuth 2 world in severa= l different ways. As such, we as a WG should be paying attention to them, a= nd if there are things we can do in our design to allow for that kind of de= ployment then we need to consider them. That doesn=E2=80=99t mean we have t= o have that fully specified in the core protocol, but if there=E2=80=99s a = way to design this so that it can be extended in that direction without the= kind of hacks that the OAuth 2 solutions have to rely on, then it=E2=80=99= ll be better for everyone. This can=E2=80=99t distract us from solving the = core use cases, or drive us to making the core so complex that it becomes i= rrelevant, but we shouldn=E2=80=99t be blind to these other possibilities.<= div>
In my opinion as a contributor, the best opportunities w= e have for that kind of extension in the way the protocol=E2=80=99s built r= ight now are in the interaction and continuation pieces of GNAP. Interactio= n we=E2=80=99ve always known was going to allow for a move off-browser, and= less dependence on user-in-a-browser is baked into the charter as well. Bu= t we need more experience and more details about :how: that works, and that= =E2=80=99s a lot of what this current conversation is going to be about. Yo= u are completely right that there are another set of challenges, but in my = mind it=E2=80=99s that the trust model is simply different. What do I trust= more, a device in my pocket or a web server in someone else=E2=80=99s data= center? There isn=E2=80=99t an easy or universal answer to that question, = as it turns out.

=C2=A0=E2=80=94 Justin

=
On Feb 7, 2021, at 5:51 PM, Francis Pouatcha= <fpo@adorsys.de> wrote:

Hello Fabian,

I am sorry fo= r the delayed reply, but very busy working on those decentralized use cases= where tokens a produced on the user device.

Like we can see i= n this thread, it is not obvious to have those use cases considered in GNAP= (as the GNAP charter mentions reliance on HTTP based AS).

If the role of an AS is to produce an authorization, a use= r device hosted AS can be build, but the negotiation process will be differ= ent from the one defined by GNAP. Means interaction protocol will need more= than just HTTP.

The biggest challenge we a= re facing on user device produced auth tokens is on how to preserve those c= rypto keys held on user device from malware, loss of device...

For the moment keeping focus of GNAP on (http) server-b= ased production of token looks like a good decision.

I will review the draft sometime as soon as possible and provide = my feedback.

<= div style=3D"font-style:normal;font-variant-caps:normal;font-weight:normal;= letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;= white-space:normal;word-spacing:0px;text-decoration:none;font-family:Calibr= i,Arial,Helvetica,sans-serif;font-size:12pt">Best regards,

/Francis

<= /div>
From:=C2=A0TXA= uth <txauth-bounces@ietf.org> on behalf of Fabien Imbault &l= t;fabien.imbault@gmail.com>
Sent:=C2=A0= Friday, February 5, 2021 3:41 PM
To:=C2=A0Adrian Gro= pper <agropper@healthurl.com>
Cc:=C2=A0Tom Jones <thomasclinganjones@gmail.com>; txauth gnap = <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subj= ect:=C2=A0Re: [GNAP] Review of draft-ietf-gnap-core-protoc= ol-00
=C2=A0
H= i Adrian,

We would be glad to = get your expertise on that. Not sure DIDComm is essential yet, so far I see= it personally as something to look into, especially for use cases when we = want to reach out to a RO. I agree with the potential issues.=C2=A0

I have a few ideas on how to im= plement privacy, but it's quite involved in terms of crypto (again usin= g Ristretto groups :-)).

Of course there will be a question of priority in the features we plan to = implement. I guess we should aim for a first publication without the parts = which are blurry, and take the time to prototype the rest.=C2=A0

Cheers
Fabi= en=C2=A0

Le ven. 5 f=C3=A9vr. 2021 =C3= =A0 21:19, Adrian Gropper <agropper@healthurl.com> a =C3=A9cr= it=C2=A0:
There are privacy implications as well as th= e cost of processing spam. A service endpoint associated with a DID can be = presumed to be a public broadcast. Any party can attempt to send a message = or an authorization request to that service endpoint. The operator of that = service, typically the DID controller, will bear the cost and risk of proce= ssing the message. They may request a bond be posted by the party respondin= g to the "broadcast" in order to mitigate spam and phishing. They= may also require that the party seeking to communicate offer credentials, = which poses a privacy risk to that party in the form of phishing "broa= dcasts" via DIDs and lures that lead to DIDs.=C2=A0

In my role as invited expert on privacy to some W3C WGs and, to some exten= t, DIF WGs, I have not managed to understand the privacy engineering and im= plications in DIDcomm. I will try harder if DIDcomm has an essential role w= ith GNAP and I can understand it in the self-sovereign or fiduciary authori= zation server context. Does it?

Adrian
=
On Fri, Feb 5, 2021 at 1:08 PM Fabien Imbault <= ;fabien.imbault@gmail.com> wrote:
Probably (and to be honest even for industrial users I find it complex)= , but alternatives are not ready for prime time either.=C2=A0
Maybe som= e day=C2=A0DIDComm could be useful as a basic block, what we suggest is to = first use that as a potential interaction (and there's already a lot of= questions that arise just from that).=C2=A0

Fabie= n

On Fri, Feb 5, 2021 at 6:55 PM Tom J= ones <thomasclinganjones@gmail.com> wrote:
No, you didn't misunderstand me. It's just tha= t the ux for that is not acceptable to retail users. As long as gnap sticks= to industrial users you should do fine.

thx ..Tom (mobile)

On Fri, Feb 5, 2021, 7:56 AM Fabien Imbau= lt <fabien.imbault@gmail.com> wrote:
Targeting existing browsers and types of a= pplications (web, pwa, mobile, etc.) seems like a reasonable option for an = industrial standard. Improving security, privacy, ease of use and interoper= ability (including decentralized identity as well) should be good enough ob= jectives.=C2=A0
Plus from our previous discussions, I was under t= he impression you were fine with the approach of deploying the AS on the ph= one as a loopback, for mobile apps. Did I miss something?

Cheers,
Fabien

Le ven. 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jone= s <thomasclinganjones@gmail.com> = a =C3=A9crit=C2=A0:
If you mean can GNAP work on = old fashioned apps running with existing browsers and existing identity pro= viders, then yes, i guess you are ok.

If you want = to work on apps where the user is in control of authn and authz, then no, G= NAP cannot work. It is not alone in that OIDC wont work there either.
=

= Be the change you want to see in the world ..tom


On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Tom,=C2=A0

Thanks, your responses made it clearer for me = what you expect from an AS deployed on a mobile.=C2=A0

I think we're on the right path to meet = the rest of your concerns. There are already a few items on these:
- privacy preserving techniques have been discussed and are = likely to be included (I think). It's been recognized as a core concern= =C2=A0
- not exactly sure the meaning you give to di= scovery here (it's already been used in the WG but with a different mea= ning I believe). The request or the continuation api provide entry points t= o pay attention to.=C2=A0

Is that eno= ugh for your use case ? Do you need something else ? (like SSE?)

Cheers
Fabi= en=C2=A0

Le jeu. 4 f=C3=A9vr. 2= 021 =C3=A0 22:10, Tom Jones <thomascli= nganjones@gmail.com> a =C3=A9crit=C2=A0:
disco= very is the prime problem.=C2=A0 What causes the wallet/AS to wake up and p= ay attention. How does the RP know what to ask for without violating user p= rivacy rights?

CHAPI would be ok i guess, but that requi= res cred man to be fixed. Not sure if it fixes discovery or privacy even th= en.

<= span style=3D"background-color:rgb(242,242,242);font-size:14px;white-space:= pre-wrap">Be the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 12:45 PM Justin Richer <jricher@mit.edu> wrote:
Tom, what additio= nal functionality do you see that a browser would need to support in order = for GNAP to be adopted? For the elements of the core protocol today, nothin= g is needed to change within the browsers =E2=80=94 everything is built on = existing functions. GNAP uses browsers as a tool, and I would argue depends= on them even less so than OAuth 2 does. Extensions could use browser funct= ionality, like using CHAPI to pass interaction elements, but the core proto= col functions on vanilla browsers today.

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

On Feb 4, 2021, at 3:20 = PM, Tom Jones <thomasclinga= njones@gmail.com> wrote:

i assumed th= at the wallet (aka AS) needed to be a native app, not a PWA (which can come= from a traditional web server).
There are folks, lke Kim C, who are wo= rking on a PWA, but i agree the blocks there seem to be large.
TH= e blocks on a native app are simple, easy to describe, and easy to ask the = browser guys to fix. Not sure if they care tho.
I have trouble se= eing a path to GNAP adoption for retail customers w/o some browser support.=
That's why i am mostly=C2=A0silent here.

Be the chan= ge you want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Fair enough. But loopback limits a lot what you can do... Just for d= ebug it's a pain.=C2=A0
But as soon as you try more, i= t's a bit crazy. Fun to test ipv6 (luckily supported by my ISP) and ddn= s. But it feels really hacky.=C2=A0
Also deployment = is a pain, compared to a traditional webserver.=C2=A0

<= div dir=3D"ltr">Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit=C2=A0:
=
doesn't work very well on windows uwp. works fine on smartp= hones
Be the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 11:18 AM Justin Richer <jricher@mi= t.edu> wrote:
OK, thanks =E2=80=94 in that case, there are = no changes at all to GNAP, which is already HTTP driven. The harder parts t= end to be where you can=E2=80=99t (or don=E2=80=99t want to) use something = like that.

=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 2:16 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

yes, loopback

Be the change you want to see in the w= orld ..tom


On Thu, Feb 4, 2021 at 11:01 AM Justin Richer <jricher@mi= t.edu> wrote:
Tom, can you expand on how exactly the back-c= hannel =C2=A0communication works between on-device components? Do you use H= TTP locally?

Thanks,
=C2=A0=E2=80=94 Justin

On Feb 4, 2021, at 1:03 PM, Tom Jo= nes <thomasclinganjones@gmail.com> wrote= :

Justin's analysis of use of the front = channel is misleading.
It could equally be argued that what i have done= is installed an AS on the phone and the communications with it & the P= R is back channel.
Basically the point is that the old OIDC parad= igms are no longer valid.
Be the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault <f= abien.imbault@gmail.com> wrote:
Yes, issue (#16= 8)=C2=A0message based interaction / DIDComm is a tentative alternative meca= nism for the interaction part. Not sure how that would work in details=C2= =A0though, prototyping will probably help here.
Token delivery=C2=A0thr= ough continuation seems fine to me. The client will probably have to wait f= or the next polling before it receives a token issued as the result of an a= synchronous interaction, but that's not a big issue.

But the AS on the phone seems like a harder nut to crack, at least a= t first sight. I think that would be awesome, but it gives me headaches, so= I think I'll work on easier stuff right now ;-)

Fabien=C2=A0=C2=A0

On Thu, Feb = 4, 2021 at 4:30 PM Justin Richer <jricher@mit.edu> wr= ote:
One of the biggest drawbacks of the current app-centric appro= aches in OIDC (self-issued OP, or SIOP) is that they depend on using the fr= ont channel and browser redirects to pass everything, which is something th= at GNAP is deliberately getting away from by starting in the back channel.<= div>
That said, once a request is kicked off in GNAP, the int= eraction and fulfillment can happen through any number of means. Part of th= e work that=E2=80=99s being done with the =E2=80=9Cinteraction=E2=80=9D sec= tion is going to help facilitate this, and I think that there are some othe= r potential branches here.

Token delivery is where= things get extra weird though =E2=80=94 we are explicitly not delivering t= okens in the front channel in the core of GNAP, we=E2=80=99re using the res= ponse from the continuation API. One idea (that isn=E2=80=99t particularly = well thought out and hasn=E2=80=99t been implemented at all) is to have an = extension declare an alternative response from the =E2=80=9Ccontinue=E2=80= =9D section that=E2=80=99s defined today, which points to the GNPA continua= tion API. If an extension defines some alternative way to deliver tokens, t= hat could live alongside a continuation API and the client could indicate s= upport for it in its initial request.

In any event= , alternative interaction and delivery methods are important, and even if w= e aren=E2=80=99t going to support every last one of them directly, the prot= ocol design should at least be aware of them.

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

On Feb 4, 20= 21, at 8:35 AM, Fabien Imbault <fabien.imbault@gmai= l.com> wrote:

Hi Tom,=C2=A0

<= /div>
Sure, any experience on that would be greatly appreciated, we'= ;re calling for help here (the point being that I suspect what they're = doing is not trivial).

Fabien

=
On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
I've had such an app working for over a year. There are issues which= are being addressed by the browser Interaction team of oidc.

t= hx ..Tom (mobile)


Hi Francis,

I've= thought a bit more to what you said. I think I'll give it a try as a s= eparate experiment (in code, not in theory). Not that I would expect it to = be included in GNAP, but I kind of like the idea :-)

The direct impact for GNAP would be to think a= bout multiple ASs.=C2=A0

Will let you know.=C2=A0

Fabien=C2=A0


Le mer. 18 nov. 2020 =C3= =A0 13:06, Francis Pouatcha <fpo@adorsys.de>= ; a =C3=A9crit=C2=A0:
It would be nice if the protoc= ol was designed at many layers of abstraction.

  • = The first layer shall design abstract protocol flows, without specification= of the mode and mechanism of interaction.
  • The second layer can ins= tantiate the first layer for dedicated interaction. Here we can talk http, = we can define interactions that presume server based token generation, we c= an define interaction that run on user device based token generation.
    • <= /ul>
    This is also the fundament of the structure I proposed for the spe= c (http= s://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30).
    /Francis

From:=C2=A0Fabien Imba= ult <fabien.imbault@gmail.com= >
Sent:=C2=A0Wednesday, November 18, 2020 6:3= 5 AM
To:=C2=A0Francis Pouatcha <fpo@adorsys.de>
Cc:=C2=A0txauth@ietf.org=C2=A0<txauth@ietf.org>; Dick Hardt <dick.hardt@gmail.com>; Tom Jones = <thomasclinganjones@gmail= .com>; Denis <denis.ietf@fre= e.fr>; Justin Richer <jricher@m= it.edu>
Subject:=C2=A0Re: [GNAP] Review of dr= aft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HTTP. Henc= e the discussion about deep links and so on.

An alternat= ive might be provided by wasm/wasi (running a local sandbox on your phone, = for your own AS), but it's really early stage. This also poses another = question that Denis has put forward, i.e. how do we handle the multiple AS = scenario (likely to occur then).=C2=A0

Fabien=C2= =A0

On Wed, Nov 18, 2020 at 12:16 PM F= rancis Pouatcha <fpo@adorsys.de>= wrote:
We are d= rifting away from the original problem space.
  • My original me= ntion was about the "POST" request, that subsumes that the "= AS" is a "Server". Designing a new protocol, we cannot affor= d this limitation.
  • I just mentioned SIOP to show a known and closed= example? Let us not focus on the device local discovery scheme (like openi= d:) for now.
  • As capability of holding private keys on user device e= volves, server-based issuing of token will be fading out giving way to devi= ce local generation of token.
While designing GNAP, let us as= sume the AS-Role can be exercised on a user device and design the protocol = to honor that.

Best regards,
/Francis
From:=C2=A0TXAuth <txauth-bounces@ietf.org> on beha= lf of Dick Hardt <dick.hardt@gmai= l.com>
Sent:=C2=A0Tuesday, November 17, 2020 = 1:28 PM
To:=C2=A0Tom Jones <thomasclinganjones@gmail.com>
Cc:=C2=A0Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@free.fr>; GNAP Mailing List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject:=C2= =A0Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
= =C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to handle= the openid: scheme? ... and that it is the user's wallet rather than s= ome malware that has registered openid: on the mobile device?
A native app can attempt to open a deep link associated with an= app, and will fail if the app is not there. If the app is there, it will b= e opened, so this can't be used to silently test if an app is present, = but it does allow a native app to provide an alternative experience if an a= pp is not present. I don't think this works with custom schemes ... and= I don't know how it could work from a web app on the phone with the cu= rrent Safari APIs.

Apple warns against using custo= m schemes [1] ... but perhaps they can be convinced to make openid: a manag= ed scheme similar to mailto:, tel:, sms:, facetime: ?

<= div>[1]=C2=A0https://developer.apple.com/documentation/xcode/allowing_app= s_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_you= r_app


3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones= <thomasclinganjones@gmai= l.com> wrote:
You are - that is not standa= rd which is opeind://
This is the one step that still needs to be= optimized for SIOP to have good UX.
Peace ..tom


=
On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom

I watched your video (I watched at= 2X speed)

Looks like the employment website app t= hat is using localhost:8765 to communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7
On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <= thomasclinganjones@gmail.com= > wrote:
Well, here's a demo. Note that in = this case the AS is not online all of the time, so it is really implicit fl= ow and the OIDC id-token comes from the siop device directly.
(whether = this is front-channel or back channel is no longer an interesting question.= )
Now if an always-on AS is required, that is possible, but probabl= y beyond the scope of this effort and would require something like an agent= -in-the-sky=C2=A0(with diamonds).
= here is the link to the 9 min video=C2=A0=C2=A0=C2=A0https://youtu.= be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Ric= her <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hur= dle isn=E2=80=99t technical compatibility so much as it is trust compatibil= ity. The RP (client) needs to have some incentive to trust the assertions a= nd identity information that=E2=80=99s coming from the AS. The same is true= for an RS trusting tokens from the AS. The hard question is less =E2=80=9C= how=E2=80=9D to do that (which SSI answers), but more =E2=80=9Cwhy=E2=80=9D= to do that (which SSI doesn=E2=80=99t answer very well, because it=E2=80= =99s a hard question).

Still: it=E2=80=99s definitely a = question about how to support this =E2=80=9CAS on device=E2=80=9D element. = We=E2=80=99ve got the start of it more than OAuth2/OIDC have by allowing th= e bootstrap of the process from a starting call: the interaction and contin= uation URIs handed back by the AS don=E2=80=99t need to be the same URIs th= at the client starts with, so just like SIOP the process can start in HTTP = and potentially move to other communication channels. A major difference is= that we aren=E2=80=99t dependent on the assumption that the user will alwa= ys be in a browser at some stage, and so the whole raft of front-channel me= ssages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve go= t an opportunity to more explicitly open up alternative communication chann= els here, and that=E2=80=99s something I=E2=80=99d like to see engineered, = even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete propo= sal as to how that would work over specific protocols, starting with what w= e=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Just= in

On Nov 17, 2020, at 12:03 PM,= Fabien Imbault <fabien.imbau= lt@gmail.com> wrote:

Hi Denis, hi Fra= ncis,=C2=A0

At some point integration with SSI (on the a= uthentication side) will probably occur, including amongst other possibilit= ies SIOP (since they work with OpenID a part of the work will probably be m= ade easier).=C2=A0

That being said, Denis is right= . It's not an AS. Technically it's entirely possible to rely on a d= ecentralized wallet (for instance on your phone) and a centralized AS. I kn= ow of a few studies on how to decentralize the AS itself (for instance=C2= =A0https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02)= .
Maybe it exists, but I'm still looking for real scenarios (= or even architectures) where an AS is deployed directly on a phone, and und= er the sole authority of the RO, while being compatible with the rest of th= e world.=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
<= blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l= eft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<= div>Hello=C2=A0 Francis,

See two comments in line.=


B) Current Document

Roles description shall no= t hold any assumption on the physical structure of the party fulfilling the= roles.
[FI] not sure w= hat you mean
=C2=A0[FP] fo= r example, we assume the AS is a server! In most SSI based use cases, the A= S will be running on the user device. See SIOP (https://iden= tity.foundation/did-siop/).
<= div style=3D"margin-top:0px;margin-bottom:0px">I browsed through the two dr= afts, i.e. :
  • Decentralized Identifiers (DIDs) v1.0 Core archit= ecture, data model, and representations W3C Working Draft 08 November 2020<= /li>
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working G= roup Draft
At no p= lace within these two documents, it is possible to imagine that "the A= S will be running on the user device".
From section 3 of the DIF Working Group Draft:
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], th= e SIOP will not return an access token to the RP".
An Identity Wallet is not an AS.=C2=A0

Roles:=C2=A0
-> grant endpoint of the AS: Why is this a post request?= This eliminates the chance of having user device hosted AS (no server).
[F= I] what would you propose instead?
Would also be interested to understand better the deploym= ent model when there is no server. That's something that was discussed = several times but I'm still missing the underlying architecture and use= case.
=C2=A0[FP] See above (SIOP). There will be = a lot of identity wallets operated on end user device.
See t= he above comment. Please, do not confuse an Identity Wallet with an Authent= ication Server (AS).
D= enis
-> Resource Owner (RO) : Authorizes the = request? Does it authorize the request or the access to a resource?
[FI] ye= s, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of interacti= on before we start listing interaction types.
=
[FI] yes=C2=A0

=
=
Interaction Types:
--> I prefer a classification with Redirect, Decoupled = and Embedded is. In the draft, we have one redirect and 2 decouple interact= ions and nothing else.
[FI] this should be handled as a specific discussion= item. As a reminder, how would you define embedded?

In practice there's a= t least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code
- CIBA
<= div style=3D"margin:0px;font-size:15px;background-color:rgb(255,255,255)"><= div style=3D"margin:0px">[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile= app, desktop app, ...)
  • Decoupled: different devices
  • Embedd= ed : RC carries RO authorization to AS


    • Resource A= ccess Request vs. Resource Request
    --> Bo= th are mixed up. No clarification of the context of each section.
    [FI] coul= d you clarify what you'd expect.=C2=A0 Btw on this topic, there's a= more general discussion on whether we should make a distinction or not.=C2= =A0
    [FP]: Here:
    • Resource Access Request: Requesting Access to a resource. Resp= onse is an access token (or any type of grant)
      • Resource Request: Request the resource. Respo= nse is the resource (or a corresponding execution)

    Token Content Neg= otiation
    --> Not expressed as such. This = is central to GNAP and not represented enough=C2=A0 in the document.
    <= /div>
    [FI] r= ight. This should be a specific discussion item.=C2=A0

    Requesting "User" I= nformation
    we identify two types of users: R= Q and RO. It will be better not to refer to a user in this draft, but eithe= r to a RQ or an RO.
    = [FI] yes that would avoid potential misunderstandings. = Although in the end, people will translate RQ into user=C2=A0or end-user mo= st of the time. Cf in definition, currently we have=C2=A0Requesting Party (RQ, aka "user")
    <= div style=3D"margin:0px">
    Interaction Ag= ain
    -> For each= interaction type, we will have to describe the protocol flow and the natur= e and behavior of involved Roles (Parties), Elements, Requests.
    =
    [FI] = yes=C2=A0=C2=A0

    =
    [FP] Will these and into tickets?

    Best reg= ards.
    /Francis



    <= /div>--=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth=
    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txa= uth

    --=C2=A0TXAuth mailing list
    TXAuth@ietf.org<= /a>
    h= ttps://www.ietf.org/mailman/listinfo/txauth
    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    --=C2=A0
    TXAuth mailing= list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    <= /div>

    = --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    <= /div><= /div>--=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    --00000000000012bfb905bad30ea9-- From nobody Mon Feb 8 06:57:47 2021 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 7EFF83A17FF for ; Mon, 8 Feb 2021 06:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 sb_qkrezSqc0 for ; Mon, 8 Feb 2021 06:57:40 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 EB8533A17FE for ; Mon, 8 Feb 2021 06:57:39 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id u20so15217607iot.9 for ; Mon, 08 Feb 2021 06:57:39 -0800 (PST) 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=FrQDTuJpA2pK5nrJ13kwXx/XDHsA+elQHCD67YJ+7k8=; b=EkAe1FeTcheuStNLJgiMPIGDLWb3l+zxrivgsMFgOUqHaXANkJmHQwrhLzQh/OAOMy Zg2kuyVlLKzA/x7j9SfEpWGzjngqpmcfmQ8k3onsw5vtHF5vON+sd92A4dESI1ZHurJs 8zHnDHIvQmrpbew/UAiwg5sXMQghRZwVI5ml1YF8SqucZGdm2iNs2cTt3dssUl0WYhbT NQzh9b8aPEkGG1loyKrA0ROCPfEVcm9JvVMkelTNhjyoE7E+g6PWFwvBlzk+Ht7Ssrwj 1Gt+OGPXwUGNXr33+5wLc1eXtuREcPkl2Z+jX7mwl2Zkh7bBmAUnPehXTG3pdRhrFH22 nk9g== 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=FrQDTuJpA2pK5nrJ13kwXx/XDHsA+elQHCD67YJ+7k8=; b=P/7ZDpIxLDT8gBNsFDeHfblusZ0da8/RuPdmzolWCmhwH2yoCM8U+YRQCk3gpMC53V Lstf2pkMvIkYTLQTsV2fiwz/wM1Z25C7n8Ob1LU5LK4wkZnzIzF4NB+0QxmRHE8swxHl cmsZzoyP0UFVfaS2FGxf2QBPRBD6YKKnoOwT4SAVvEH5wq2wkcAd6CUrpztUIftQMJEr cGMBglhZQJkZf1RUEuxTGsOfqHBwIOibdPuUc2aQzHWM6+YCpEevwShS95O1r1unPr/z 3MVn92b5R49wV990/hB3ZupbnRCAOauT86V1a5n5aHuHq8TU5BwSnkWy7B86+3XoGZKo sJvg== X-Gm-Message-State: AOAM533OP40VKByW3eThKglboS/v6zkxgoJX7aF4HneoGNNHk+4Fey5w 8UcPYOiKJo5qayORMiXyGck6R3Z86uxcMugVANY= X-Google-Smtp-Source: ABdhPJycRpxY4vnY9iylc1V0zLe707HxPUuIVL1M91Pz+fyVg6dljljDAE69jHLSYQ6MmQBblBoLu36iYIoVAPyCBNY= X-Received: by 2002:a02:69cf:: with SMTP id e198mr18897981jac.108.1612796258003; Mon, 08 Feb 2021 06:57:38 -0800 (PST) MIME-Version: 1.0 References: <7A612194-5C4B-4658-B7F0-E6058D044255@mit.edu> In-Reply-To: From: Fabien Imbault Date: Mon, 8 Feb 2021 15:57:24 +0100 Message-ID: To: Tom Jones Cc: Justin Richer , Francis Pouatcha , Adrian Gropper , txauth gnap Content-Type: multipart/alternative; boundary="0000000000000db01c05bad464cc" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 14:57:46 -0000 --0000000000000db01c05bad464cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 The interim meeting planned on Wednesday will be a good opportunity to discuss interactions ! Fabien On Mon, Feb 8, 2021 at 2:22 PM Tom Jones wrote: > Justin +1 > > thx ..Tom (mobile) > > On Mon, Feb 8, 2021, 5:19 AM Justin Richer wrote: > >> I agree that the focus of this group does need to be on an HTTP-based AS >> =E2=80=94 this particular use case is the one that we have to solve for,= and that=E2=80=99s >> why those details are called out in the charter. We aren=E2=80=99t here = to try to >> build a transport-independent security language, with abstractions and >> bindings and things of that sort. But that said, the =E2=80=9Con-device = AS=E2=80=9D use >> case is being brought up a lot, and solutions have been hacked together = in >> the OAuth 2 world in several different ways. As such, we as a WG should = be >> paying attention to them, and if there are things we can do in our desig= n >> to allow for that kind of deployment then we need to consider them. That >> doesn=E2=80=99t mean we have to have that fully specified in the core pr= otocol, but >> if there=E2=80=99s a way to design this so that it can be extended in th= at >> direction without the kind of hacks that the OAuth 2 solutions have to r= ely >> on, then it=E2=80=99ll be better for everyone. This can=E2=80=99t distra= ct us from solving >> the core use cases, or drive us to making the core so complex that it >> becomes irrelevant, but we shouldn=E2=80=99t be blind to these other pos= sibilities. >> >> In my opinion as a contributor, the best opportunities we have for that >> kind of extension in the way the protocol=E2=80=99s built right now are = in the >> interaction and continuation pieces of GNAP. Interaction we=E2=80=99ve a= lways known >> was going to allow for a move off-browser, and less dependence on >> user-in-a-browser is baked into the charter as well. But we need more >> experience and more details about :how: that works, and that=E2=80=99s a= lot of >> what this current conversation is going to be about. You are completely >> right that there are another set of challenges, but in my mind it=E2=80= =99s that >> the trust model is simply different. What do I trust more, a device in m= y >> pocket or a web server in someone else=E2=80=99s data center? There isn= =E2=80=99t an easy >> or universal answer to that question, as it turns out. >> >> =E2=80=94 Justin >> >> On Feb 7, 2021, at 5:51 PM, Francis Pouatcha wrote: >> >> Hello Fabian, >> >> I am sorry for the delayed reply, but very busy working on those >> decentralized use cases where tokens a produced on the user device. >> >> >> Like we can see in this thread, it is not obvious to have those use case= s >> considered in GNAP (as the GNAP charter mentions reliance on HTTP based = AS). >> >> If the role of an AS is to produce an authorization, a user device hoste= d >> AS can be build, but the negotiation process will be different from the = one >> defined by GNAP. Means interaction protocol will need more than just HTT= P. >> >> The biggest challenge we are facing on user device produced auth tokens >> is on how to preserve those crypto keys held on user device from malware= , >> loss of device... >> >> For the moment keeping focus of GNAP on (http) server-based production o= f >> token looks like a good decision. >> >> I will review the draft sometime as soon as possible and provide my >> feedback. >> >> Best regards, >> >> /Francis >> >> ------------------------------ >> *From:* TXAuth on behalf of Fabien Imbault < >> fabien.imbault@gmail.com> >> *Sent:* Friday, February 5, 2021 3:41 PM >> *To:* Adrian Gropper >> *Cc:* Tom Jones ; txauth gnap < >> txauth@ietf.org>; Justin Richer >> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >> >> Hi Adrian, >> >> We would be glad to get your expertise on that. Not sure DIDComm is >> essential yet, so far I see it personally as something to look into, >> especially for use cases when we want to reach out to a RO. I agree with >> the potential issues. >> >> I have a few ideas on how to implement privacy, but it's quite involved >> in terms of crypto (again using Ristretto groups :-)). >> >> Of course there will be a question of priority in the features we plan t= o >> implement. I guess we should aim for a first publication without the par= ts >> which are blurry, and take the time to prototype the rest. >> >> Cheers >> Fabien >> >> Le ven. 5 f=C3=A9vr. 2021 =C3=A0 21:19, Adrian Gropper a >> =C3=A9crit : >> >> There are privacy implications as well as the cost of processing spam. A >> service endpoint associated with a DID can be presumed to be a public >> broadcast. Any party can attempt to send a message or an authorization >> request to that service endpoint. The operator of that service, typicall= y >> the DID controller, will bear the cost and risk of processing the messag= e. >> They may request a bond be posted by the party responding to the >> "broadcast" in order to mitigate spam and phishing. They may also requir= e >> that the party seeking to communicate offer credentials, which poses a >> privacy risk to that party in the form of phishing "broadcasts" via DIDs >> and lures that lead to DIDs. >> >> In my role as invited expert on privacy to some W3C WGs and, to some >> extent, DIF WGs, I have not managed to understand the privacy engineerin= g >> and implications in DIDcomm. I will try harder if DIDcomm has an essenti= al >> role with GNAP and I can understand it in the self-sovereign or fiduciar= y >> authorization server context. Does it? >> >> Adrian >> >> On Fri, Feb 5, 2021 at 1:08 PM Fabien Imbault >> wrote: >> >> Probably (and to be honest even for industrial users I find it complex), >> but alternatives are not ready for prime time either. >> Maybe some day DIDComm could be useful as a basic block, what we suggest >> is to first use that as a potential interaction (and there's already a l= ot >> of questions that arise just from that). >> >> Fabien >> >> On Fri, Feb 5, 2021 at 6:55 PM Tom Jones >> wrote: >> >> No, you didn't misunderstand me. It's just that the ux for that is not >> acceptable to retail users. As long as gnap sticks to industrial users y= ou >> should do fine. >> >> thx ..Tom (mobile) >> >> On Fri, Feb 5, 2021, 7:56 AM Fabien Imbault >> wrote: >> >> Targeting existing browsers and types of applications (web, pwa, mobile, >> etc.) seems like a reasonable option for an industrial standard. Improvi= ng >> security, privacy, ease of use and interoperability (including >> decentralized identity as well) should be good enough objectives. >> Plus from our previous discussions, I was under the impression you were >> fine with the approach of deploying the AS on the phone as a loopback, f= or >> mobile apps. Did I miss something? >> >> Cheers, >> Fabien >> >> Le ven. 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones a >> =C3=A9crit : >> >> If you mean can GNAP work on old fashioned apps running with existing >> browsers and existing identity providers, then yes, i guess you are ok. >> >> If you want to work on apps where the user is in control of authn and >> authz, then no, GNAP cannot work. It is not alone in that OIDC wont work >> there either. >> >> Be the change you want to see in the world ..tom >> >> >> On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault >> wrote: >> >> Hi Tom, >> >> Thanks, your responses made it clearer for me what you expect from an AS >> deployed on a mobile. >> >> I think we're on the right path to meet the rest of your concerns. There >> are already a few items on these: >> - privacy preserving techniques have been discussed and are likely to be >> included (I think). It's been recognized as a core concern >> - not exactly sure the meaning you give to discovery here (it's already >> been used in the WG but with a different meaning I believe). The request= or >> the continuation api provide entry points to pay attention to. >> >> Is that enough for your use case ? Do you need something else ? (like >> SSE?) >> >> Cheers >> Fabien >> >> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom Jones a >> =C3=A9crit : >> >> discovery is the prime problem. What causes the wallet/AS to wake up an= d >> pay attention. How does the RP know what to ask for without violating us= er >> privacy rights? >> >> CHAPI would be ok i guess, but that requires cred man to be fixed. Not >> sure if it fixes discovery or privacy even then. >> >> Be the change you want to see in the world ..tom >> >> >> On Thu, Feb 4, 2021 at 12:45 PM Justin Richer wrote: >> >> Tom, what additional functionality do you see that a browser would need >> to support in order for GNAP to be adopted? For the elements of the core >> protocol today, nothing is needed to change within the browsers =E2=80= =94 >> everything is built on existing functions. GNAP uses browsers as a tool, >> and I would argue depends on them even less so than OAuth 2 does. >> Extensions could use browser functionality, like using CHAPI to pass >> interaction elements, but the core protocol functions on vanilla browser= s >> today. >> >> =E2=80=94 Justin >> >> On Feb 4, 2021, at 3:20 PM, Tom Jones >> wrote: >> >> i assumed that the wallet (aka AS) needed to be a native app, not a PWA >> (which can come from a traditional web server). >> There are folks, lke Kim C, who are working on a PWA, but i agree the >> blocks there seem to be large. >> THe blocks on a native app are simple, easy to describe, and easy to ask >> the browser guys to fix. Not sure if they care tho. >> I have trouble seeing a path to GNAP adoption for retail customers w/o >> some browser support. >> That's why i am mostly silent here. >> >> Be the change you want to see in the world ..tom >> >> >> On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault >> wrote: >> >> Fair enough. But loopback limits a lot what you can do... Just for debug >> it's a pain. >> But as soon as you try more, it's a bit crazy. Fun to test ipv6 (luckily >> supported by my ISP) and ddns. But it feels really hacky. >> Also deployment is a pain, compared to a traditional webserver. >> >> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones a >> =C3=A9crit : >> >> doesn't work very well on windows uwp. works fine on smartphones >> Be the change you want to see in the world ..tom >> >> >> On Thu, Feb 4, 2021 at 11:18 AM Justin Richer wrote: >> >> OK, thanks =E2=80=94 in that case, there are no changes at all to GNAP, = which is >> already HTTP driven. The harder parts tend to be where you can=E2=80=99t= (or don=E2=80=99t >> want to) use something like that. >> >> =E2=80=94 Justin >> >> On Feb 4, 2021, at 2:16 PM, Tom Jones >> wrote: >> >> yes, loopback >> >> Be the change you want to see in the world ..tom >> >> >> On Thu, Feb 4, 2021 at 11:01 AM Justin Richer wrote: >> >> Tom, can you expand on how exactly the back-channel communication works >> between on-device components? Do you use HTTP locally? >> >> Thanks, >> =E2=80=94 Justin >> >> On Feb 4, 2021, at 1:03 PM, Tom Jones >> wrote: >> >> Justin's analysis of use of the front channel is misleading. >> It could equally be argued that what i have done is installed an AS on >> the phone and the communications with it & the PR is back channel. >> Basically the point is that the old OIDC paradigms are no longer valid. >> Be the change you want to see in the world ..tom >> >> >> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault >> wrote: >> >> Yes, issue (#168) message based interaction / DIDComm is a tentative >> alternative mecanism for the interaction part. Not sure how that would w= ork >> in details though, prototyping will probably help here. >> Token delivery through continuation seems fine to me. The client will >> probably have to wait for the next polling before it receives a token >> issued as the result of an asynchronous interaction, but that's not a bi= g >> issue. >> >> But the AS on the phone seems like a harder nut to crack, at least at >> first sight. I think that would be awesome, but it gives me headaches, s= o I >> think I'll work on easier stuff right now ;-) >> >> Fabien >> >> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer wrote: >> >> One of the biggest drawbacks of the current app-centric approaches in >> OIDC (self-issued OP, or SIOP) is that they depend on using the front >> channel and browser redirects to pass everything, which is something tha= t >> GNAP is deliberately getting away from by starting in the back channel. >> >> That said, once a request is kicked off in GNAP, the interaction and >> fulfillment can happen through any number of means. Part of the work tha= t=E2=80=99s >> being done with the =E2=80=9Cinteraction=E2=80=9D section is going to he= lp facilitate this, >> and I think that there are some other potential branches here. >> >> Token delivery is where things get extra weird though =E2=80=94 we are e= xplicitly >> not delivering tokens in the front channel in the core of GNAP, we=E2=80= =99re using >> the response from the continuation API. One idea (that isn=E2=80=99t par= ticularly >> well thought out and hasn=E2=80=99t been implemented at all) is to have = an >> extension declare an alternative response from the =E2=80=9Ccontinue=E2= =80=9D section >> that=E2=80=99s defined today, which points to the GNPA continuation API.= If an >> extension defines some alternative way to deliver tokens, that could liv= e >> alongside a continuation API and the client could indicate support for i= t >> in its initial request. >> >> In any event, alternative interaction and delivery methods are important= , >> and even if we aren=E2=80=99t going to support every last one of them di= rectly, the >> protocol design should at least be aware of them. >> >> =E2=80=94 Justin >> >> On Feb 4, 2021, at 8:35 AM, Fabien Imbault >> wrote: >> >> Hi Tom, >> >> Sure, any experience on that would be greatly appreciated, we're calling >> for help here (the point being that I suspect what they're doing is not >> trivial). >> >> Fabien >> >> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones >> wrote: >> >> I've had such an app working for over a year. There are issues which are >> being addressed by the browser Interaction team of oidc. >> >> thx ..Tom (mobile) >> >> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault >> wrote: >> >> Hi Francis, >> >> I've tried a few things with regards to using the AS on a phone, but it'= s >> really quite complex. >> >> Making that run on a phone comes with quite a bit of trouble. The most >> difficult part if that we'd need to use a secure element, but just >> installing and hosting a http server securely is not a standard setup at >> all. I suggest interested people step in to work on this, as we already >> have a lot of work for the (more usual) server case and already handle a >> privacy preserving scheme. >> >> Please let us know what you think. >> >> Cheers, >> Fabien >> >> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault >> wrote: >> >> Hi Francis, >> >> I've thought a bit more to what you said. I think I'll give it a try as = a >> separate experiment (in code, not in theory). Not that I would expect it= to >> be included in GNAP, but I kind of like the idea :-) >> >> The direct impact for GNAP would be to think about multiple ASs. >> >> Will let you know. >> >> Fabien >> >> >> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha a = =C3=A9crit : >> >> It would be nice if the protocol was designed at many layers of >> abstraction. >> >> >> - The first layer shall design abstract protocol flows, without >> specification of the mode and mechanism of interaction. >> - The second layer can instantiate the first layer for dedicated >> interaction. Here we can talk http, we can define interactions that p= resume >> server based token generation, we can define interaction that run on = user >> device based token generation. >> >> This is also the fundament of the structure I proposed for the spec ( >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). >> >> /Francis >> >> ------------------------------ >> *From:* Fabien Imbault >> *Sent:* Wednesday, November 18, 2020 6:35 AM >> *To:* Francis Pouatcha >> *Cc:* txauth@ietf.org ; Dick Hardt ; >> Tom Jones ; Denis ; >> Justin Richer >> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >> >> Would make sense, but not so easy as we rely heavily on HTTP. Hence the >> discussion about deep links and so on. >> >> An alternative might be provided by wasm/wasi (running a local sandbox o= n >> your phone, for your own AS), but it's really early stage. This also pos= es >> another question that Denis has put forward, i.e. how do we handle the >> multiple AS scenario (likely to occur then). >> >> Fabien >> >> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha wrote= : >> >> We are drifting away from the original problem space. >> >> - My original mention was about the "POST" request, that subsumes >> that the "AS" is a "Server". Designing a new protocol, we cannot affo= rd >> this limitation. >> - I just mentioned SIOP to show a known and closed example? Let us >> not focus on the device local discovery scheme (like openid:) for now= . >> - As capability of holding private keys on user device evolves, >> server-based issuing of token will be fading out giving way to device= local >> generation of token. >> >> While designing GNAP, let us assume the AS-Role can be exercised on a >> user device and design the protocol to honor that. >> >> Best regards, >> /Francis >> ------------------------------ >> *From:* TXAuth on behalf of Dick Hardt < >> dick.hardt@gmail.com> >> *Sent:* Tuesday, November 17, 2020 1:28 PM >> *To:* Tom Jones >> *Cc:* Fabien Imbault ; Denis < >> denis.ietf@free.fr>; GNAP Mailing List ; Justin Richer = < >> jricher@mit.edu> >> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >> >> Got it. >> >> So web apps invoke a openid: deep link and hope there is an app to handl= e >> the openid: scheme? ... and that it is the user's wallet rather than som= e >> malware that has registered openid: on the mobile device? >> >> A native app can attempt to open a deep link associated with an app, and >> will fail if the app is not there. If the app is there, it will be opene= d, >> so this can't be used to silently test if an app is present, but it does >> allow a native app to provide an alternative experience if an app is not >> present. I don't think this works with custom schemes ... and I don't kn= ow >> how it could work from a web app on the phone with the current Safari AP= Is. >> >> Apple warns against using custom schemes [1] ... but perhaps they can be >> convinced to make openid: a managed scheme similar to mailto:, tel:, >> sms:, facetime: ? >> >> [1] >> https://developer.apple.com/documentation/xcode/allowing_apps_and_websit= es_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app >> >> >> =E1=90=A7 >> >> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones >> wrote: >> >> You are - that is not standard which is opeind:// >> This is the one step that still needs to be optimized for SIOP to have >> good UX. >> Peace ..tom >> >> >> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt wrote: >> >> Hi Tom >> >> I watched your video (I watched at 2X speed) >> >> Looks like the employment website app that is using localhost:8765 to >> communicate with the wallet. Am I correct? >> >> /Dick >> =E1=90=A7 >> >> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones >> wrote: >> >> Well, here's a demo. Note that in this case the AS is not online all of >> the time, so it is really implicit flow and the OIDC id-token comes from >> the siop device directly. >> (whether this is front-channel or back channel is no longer an >> interesting question.) >> Now if an always-on AS is required, that is possible, but probably beyon= d >> the scope of this effort and would require something like an >> agent-in-the-sky (with diamonds). >> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 >> >> Peace ..tom >> >> >> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: >> >> Ultimately, in most situations like these in the real world, the hurdle >> isn=E2=80=99t technical compatibility so much as it is trust compatibili= ty. The RP >> (client) needs to have some incentive to trust the assertions and identi= ty >> information that=E2=80=99s coming from the AS. The same is true for an R= S trusting >> tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to d= o that (which SSI >> answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, >> because it=E2=80=99s a hard question). >> >> Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on >> device=E2=80=9D element. We=E2=80=99ve got the start of it more than OAu= th2/OIDC have by >> allowing the bootstrap of the process from a starting call: the interact= ion >> and continuation URIs handed back by the AS don=E2=80=99t need to be the= same URIs >> that the client starts with, so just like SIOP the process can start in >> HTTP and potentially move to other communication channels. A major >> difference is that we aren=E2=80=99t dependent on the assumption that th= e user will >> always be in a browser at some stage, and so the whole raft of >> front-channel messages that SIOP relies on doesn=E2=80=99t fly. That sai= d, we=E2=80=99ve >> got an opportunity to more explicitly open up alternative communication >> channels here, and that=E2=80=99s something I=E2=80=99d like to see engi= neered, even if >> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete proposal a= s to how that would >> work over specific protocols, starting with what we=E2=80=99ve got today= . >> >> =E2=80=94 Justin >> >> On Nov 17, 2020, at 12:03 PM, Fabien Imbault >> wrote: >> >> Hi Denis, hi Francis, >> >> At some point integration with SSI (on the authentication side) will >> probably occur, including amongst other possibilities SIOP (since they w= ork >> with OpenID a part of the work will probably be made easier). >> >> That being said, Denis is right. It's not an AS. Technically it's >> entirely possible to rely on a decentralized wallet (for instance on you= r >> phone) and a centralized AS. I know of a few studies on how to decentral= ize >> the AS itself (for instance >> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >> Maybe it exists, but I'm still looking for real scenarios (or even >> architectures) where an AS is deployed directly on a phone, and under th= e >> sole authority of the RO, while being compatible with the rest of the >> world. >> >> Cheers, >> Fabien >> >> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >> >> Hello Francis, >> >> See two comments in line. >> >> >> B) Current Document >> >> Roles description shall not hold any assumption on the physical structur= e >> of the party fulfilling the roles. >> [FI] not sure what you mean >> >> [FP] for example, we assume the AS is a server! In most SSI based use >> cases, the AS will be running on the user device. See SIOP ( >> https://identity.foundation/did-siop/). >> >> I browsed through the two drafts, i.e. : >> >> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >> model, and representations W3C Working Draft 08 November 2020 >> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working >> Group Draft >> >> At no place within these two documents, it is possible to imagine that >> "the AS will be running on the user device". >> From section 3 of the DIF Working Group Draft: >> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the >> SIOP will not return an access token to the RP". >> An Identity Wallet is not an AS. >> >> >> Roles: >> -> grant endpoint of the AS: Why is this a post request? This eliminates >> the chance of having user device hosted AS (no server). >> [FI] what would you propose instead? >> Would also be interested to understand better the deployment model when >> there is no server. That's something that was discussed several times bu= t >> I'm still missing the underlying architecture and use case. >> >> [FP] See above (SIOP). There will be a lot of identity wallets operated >> on end user device. >> >> See the above comment. Please, do not confuse an Identity Wallet with an >> Authentication Server (AS). >> Denis >> >> >> -> Resource Owner (RO) : Authorizes the request? Does it authorize the >> request or the access to a resource? >> [FI] yes, we should make the wording clearer >> >> Missing Section Interactions: >> --> This section shall introduce the notion of interaction before we >> start listing interaction types. >> [FI] yes >> >> Interaction Types: >> --> I prefer a classification with Redirect, Decoupled and Embedded is. >> In the draft, we have one redirect and 2 decouple interactions and nothi= ng >> else. >> [FI] this should be handled as a specific discussion item. As a reminder= , >> how would you define embedded? >> >> In practice there's at least these modes: >> - redirect and redirect back >> - redirect to different browser or device >> - user code >> - CIBA >> >> [FP] This classification is limited. >> >> - Redirect: same device, same or different user agents (browser, >> mobile app, desktop app, ...) >> - Decoupled: different devices >> - Embedded : RC carries RO authorization to AS >> >> >> >> Resource Access Request vs. Resource Request >> --> Both are mixed up. No clarification of the context of each section. >> [FI] could you clarify what you'd expect. Btw on this topic, there's a >> more general discussion on whether we should make a distinction or not. >> >> [FP]: Here: >> >> - Resource Access Request: Requesting Access to a resource. Response >> is an access token (or any type of grant) >> - Resource Request: Request the resource. Response is the resource >> (or a corresponding execution) >> >> >> Token Content Negotiation >> --> Not expressed as such. This is central to GNAP and not represented >> enough in the document. >> [FI] right. This should be a specific discussion item. >> >> Requesting "User" Information >> we identify two types of users: RQ and RO. It will be better not to refe= r >> to a user in this draft, but either to a RQ or an RO. >> [FI] yes that would avoid potential misunderstandings. Although in the >> end, people will translate RQ into user or end-user most of the time. Cf= in >> definition, currently we have Requesting Party (RQ, aka "user") >> >> >> Interaction Again >> -> For each interaction type, we will have to describe the protocol flow >> and the nature and behavior of involved Roles (Parties), Elements, Reque= sts. >> [FI] yes >> >> >> [FP] Will these and into tickets? >> >> Best regards. >> /Francis >> >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> --0000000000000db01c05bad464cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    +1=C2=A0
    The interim meeting planned on Wednesday = will be a good opportunity to discuss interactions !

    Fabien

    On Mon, Feb 8, 2021 at 2:22 PM Tom Jones <thomasclinganjones@gmail.com> wrot= e:
    Justin +1

    thx ..Tom (mobile)

    On Mon, Feb 8, 2021, 5:1= 9 AM Justin Richer <jricher@mit.edu> wrote:
    I agree that the = focus of this group does need to be on an HTTP-based AS =E2=80=94 this part= icular use case is the one that we have to solve for, and that=E2=80=99s wh= y those details are called out in the charter. We aren=E2=80=99t here to tr= y to build a transport-independent security language, with abstractions and= bindings and things of that sort. But that said, the =E2=80=9Con-device AS= =E2=80=9D use case is being brought up a lot, and solutions have been hacke= d together in the OAuth 2 world in several different ways. As such, we as a= WG should be paying attention to them, and if there are things we can do i= n our design to allow for that kind of deployment then we need to consider = them. That doesn=E2=80=99t mean we have to have that fully specified in the= core protocol, but if there=E2=80=99s a way to design this so that it can = be extended in that direction without the kind of hacks that the OAuth 2 so= lutions have to rely on, then it=E2=80=99ll be better for everyone. This ca= n=E2=80=99t distract us from solving the core use cases, or drive us to mak= ing the core so complex that it becomes irrelevant, but we shouldn=E2=80=99= t be blind to these other possibilities.

    In my opinion a= s a contributor, the best opportunities we have for that kind of extension = in the way the protocol=E2=80=99s built right now are in the interaction an= d continuation pieces of GNAP. Interaction we=E2=80=99ve always known was g= oing to allow for a move off-browser, and less dependence on user-in-a-brow= ser is baked into the charter as well. But we need more experience and more= details about :how: that works, and that=E2=80=99s a lot of what this curr= ent conversation is going to be about. You are completely right that there = are another set of challenges, but in my mind it=E2=80=99s that the trust m= odel is simply different. What do I trust more, a device in my pocket or a = web server in someone else=E2=80=99s data center? There isn=E2=80=99t an ea= sy or universal answer to that question, as it turns out.

    =C2=A0=E2=80=94 Justin

    On = Feb 7, 2021, at 5:51 PM, Francis Pouatcha <fpo@adorsys.de> wrote:
    Hello Fabian,

    I am sorry for the delayed reply, but very busy= working on those decentralized use cases where tokens a produced on the us= er device.


    Like we can see in this thread, it is not obvious t= o have those use cases considered in GNAP (as the GNAP charter mentions rel= iance on HTTP based AS).

    If the role of an = AS is to produce an authorization, a user device hosted AS can be build, bu= t the negotiation process will be different from the one defined by GNAP. M= eans interaction protocol will need more than just HTTP.

    The biggest challenge we are facing on user device produced a= uth tokens is on how to preserve those crypto keys held on user device from= malware, loss of device...

    For the moment = keeping focus of GNAP on (http) server-based production of token looks like= a good decision.

    I will review the draft s= ometime as soon as possible and provide my feedback.

    Best regards,
    =
    /Francis

    From:=C2=A0TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imba= ult <fabien.imbault@gmail.com>
    Sent:=C2=A0<= /span>Friday, February 5, 2021 3:41 PM
    To:=C2=A0Adri= an Gropper <agropper@healthurl.com>
    Cc:=C2=A0= Tom Jones <thomasclinganjones@gmail.com>; txauth= gnap <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
    <= b>Subject:=C2=A0Re: [GNAP] Review of draft-ietf-gnap-core-= protocol-00
    =C2=A0
    Hi Adrian,

    We would be gl= ad to get your expertise on that. Not sure DIDComm is essential yet, so far= I see it personally as something to look into, especially for use cases wh= en we want to reach out to a RO. I agree with the potential issues.=C2=A0

    I have a few ideas on how= to implement privacy, but it's quite involved in terms of crypto (agai= n using Ristretto groups :-)).

    Of course there will be a question of priority in the features we pl= an to implement. I guess we should aim for a first publication without the = parts which are blurry, and take the time to prototype the rest.=C2=A0

    Cheers
    Fabien=C2=A0

    Le ven. 5 f=C3=A9vr. 20= 21 =C3=A0 21:19, Adrian Gropper <agropper@healthurl.com> a = =C3=A9crit=C2=A0:
    The= re are privacy implications as well as the cost of processing spam. A servi= ce endpoint associated with a DID can be presumed to be a public broadcast.= Any party can attempt to send a message or an authorization request to tha= t service endpoint. The operator of that service, typically the DID control= ler, will bear the cost and risk of processing the message. They may reques= t a bond be posted by the party responding to the "broadcast" in = order to mitigate spam and phishing. They may also require that the party s= eeking to communicate offer credentials, which poses a privacy risk to that= party in the form of phishing "broadcasts" via DIDs and lures th= at lead to DIDs.=C2=A0

    In my role as invited expert on p= rivacy to some W3C WGs and, to some extent, DIF WGs, I have not managed to = understand the privacy engineering and implications in DIDcomm. I will try = harder if DIDcomm has an essential role with GNAP and I can understand it i= n the self-sovereign or fiduciary authorization server context. Does it?

    Adrian

    On Fri, = Feb 5, 2021 at 1:08 PM Fabien Imbault <fabien.imbault@g= mail.com> wrote:
    Probably (and to be honest even for industrial users I find it complex),= but alternatives are not ready for prime time either.=C2=A0
    Maybe some= day=C2=A0DIDComm could be useful as a basic block, what we suggest is to f= irst use that as a potential interaction (and there's already a lot of = questions that arise just from that).=C2=A0

    Fabien=

    On Fri, Feb 5, 2021 at 6:55 PM Tom Jo= nes <thomasclinganjones@gmail.com> wrote:
    No, you didn't mis= understand me. It's just that the ux for that is not acceptable to reta= il users. As long as gnap sticks to industrial users you should do fine.
    thx ..Tom (mobile)

    On Fri, F= eb 5, 2021, 7:56 AM Fabien Imbault <fabien.imbault@gmai= l.com> wrote:
    =
    Targeting existing browsers and types of application= s (web, pwa, mobile, etc.) seems like a reasonable option for an industrial= standard. Improving security, privacy, ease of use and interoperability (i= ncluding decentralized identity as well) should be good enough objectives.= =C2=A0
    Plus from our previous discussions, I was under the impres= sion you were fine with the approach of deploying the AS on the phone as a = loopback, for mobile apps. Did I miss something?
    Cheers,
    Fabien

    =
    Le ven. 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9cr= it=C2=A0:
    If you= mean can GNAP work on old fashioned apps running with existing browsers an= d existing identity providers, then yes, i guess you are ok.

    =
    If you want to work on apps where the user is in control of auth= n and authz, then no, GNAP cannot work. It is not alone in that OIDC wont w= ork there either.

    Be the change you want to see in the world ..tom


    On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Tom,=C2=A0

    Thanks, your = responses made it clearer for me what you expect from an AS deployed on a m= obile.=C2=A0

    I think we&= #39;re on the right path to meet the rest of your concerns. There are alrea= dy a few items on these:
    - privacy preserving techni= ques have been discussed and are likely to be included (I think). It's = been recognized as a core concern=C2=A0
    - not exactl= y sure the meaning you give to discovery here (it's already been used i= n the WG but with a different meaning I believe). The request or the contin= uation api provide entry points to pay attention to.=C2=A0

    Is that enough for your use case ? Do you need someth= ing else ? (like SSE?)

    C= heers
    Fabien=C2=A0

    Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit= =C2=A0:
    discovery is = the prime problem.=C2=A0 What causes the wallet/AS to wake up and pay atten= tion. How does the RP know what to ask for without violating user privacy r= ights?

    CHAPI would be ok i guess, but that requires cred= man to be fixed. Not sure if it fixes discovery or privacy even then.
    <= div>
    Be the change you want to see in the world ..tom


    On Thu, Feb 4, 2021 at 12:45 PM Justin Richer <jricher@mit.edu> wrote:
    Tom, what additional functionality do you see that a browse= r would need to support in order for GNAP to be adopted? For the elements o= f the core protocol today, nothing is needed to change within the browsers = =E2=80=94 everything is built on existing functions. GNAP uses browsers as = a tool, and I would argue depends on them even less so than OAuth 2 does. E= xtensions could use browser functionality, like using CHAPI to pass interac= tion elements, but the core protocol functions on vanilla browsers today.
    =C2=A0=E2=80=94 Justin

    On Feb 4, 2021, at 3:20 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

    <= div>
    i assumed that the wallet (aka AS) needed to be a nati= ve app, not a PWA (which can come from a traditional web server).
    There= are folks, lke Kim C, who are working on a PWA, but i agree the blocks the= re seem to be large.
    THe blocks on a native app are simple, easy = to describe, and easy to ask the browser guys to fix. Not sure if they care= tho.
    I have trouble seeing a path to GNAP adoption for retail cu= stomers w/o some browser support.
    That's why i am mostly=C2= =A0silent here.

    Be the change you want to see in the world ..tom


    On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Fair enough. But loopback limits a = lot what you can do... Just for debug it's a pain.=C2=A0
    But as soon as you try more, it's a bit crazy. Fun to test ipv6 (luc= kily supported by my ISP) and ddns. But it feels really hacky.=C2=A0
    <= div dir=3D"auto">Also deployment is a pain, compared to a traditional webse= rver.=C2=A0

    Le jeu. 4 f=C3=A9vr. 2021 = =C3=A0 20:20, Tom Jones <thomasclinganjones@gmail.com&= gt; a =C3=A9crit=C2=A0:
    doesn't work very well on windows uwp. works fine on smartphones
    = Be the change you want to see in the world ..tom


    On Thu, Feb 4, 2021 at 11:18 AM Justin Richer <jricher@mi= t.edu> wrote:
    OK, thanks = =E2=80=94 in that case, there are no changes at all to GNAP, which is alrea= dy HTTP driven. The harder parts tend to be where you can=E2=80=99t (or don= =E2=80=99t want to) use something like that.

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

    On Feb 4, 2021, at= 2:16 PM, Tom Jones <thomasclinganjones@gmail.c= om> wrote:

    yes, loopback

    = Be the change you want to see in the world ..tom


    On Thu, Feb 4, 2021 at 11:01 AM Justin Richer <jricher@mi= t.edu> wrote:
    Tom, can you= expand on how exactly the back-channel =C2=A0communication works between o= n-device components? Do you use HTTP locally?

    Thanks,
    =C2=A0=E2=80=94 Justin

    O= n Feb 4, 2021, at 1:03 PM, Tom Jones <thomascli= nganjones@gmail.com> wrote:

    Justin= 9;s analysis of use of the front channel is misleading.
    It could equall= y be argued that what i have done is installed an AS on the phone and the c= ommunications with it & the PR is back channel.
    Basically the= point is that the old OIDC paradigms are no longer valid.
    Be the change you w= ant to see in the world ..tom


    On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault <f= abien.imbault@gmail.com> wrote:
    Yes, issue (#168)=C2=A0message based interaction / DIDCom= m is a tentative alternative mecanism for the interaction part. Not sure ho= w that would work in details=C2=A0though, prototyping will probably help he= re.
    Token delivery=C2=A0through continuation seems fine to me. The clie= nt will probably have to wait for the next polling before it receives a tok= en issued as the result of an asynchronous interaction, but that's not = a big issue.

    But the AS on the phone seems like a = harder nut to crack, at least at first sight. I think that would be awesome= , but it gives me headaches, so I think I'll work on easier stuff right= now ;-)

    Fabien=C2=A0=C2=A0

    On Thu, Feb 4, 2021 at 4:30 PM Justin Richer <jricher@mit.edu> wrote:
    One of the biggest drawbacks of the current app-centric approaches in OI= DC (self-issued OP, or SIOP) is that they depend on using the front channel= and browser redirects to pass everything, which is something that GNAP is = deliberately getting away from by starting in the back channel.

    That said, once a request is kicked off in GNAP, the interaction an= d fulfillment can happen through any number of means. Part of the work that= =E2=80=99s being done with the =E2=80=9Cinteraction=E2=80=9D section is goi= ng to help facilitate this, and I think that there are some other potential= branches here.

    Token delivery is where things get= extra weird though =E2=80=94 we are explicitly not delivering tokens in th= e front channel in the core of GNAP, we=E2=80=99re using the response from = the continuation API. One idea (that isn=E2=80=99t particularly well though= t out and hasn=E2=80=99t been implemented at all) is to have an extension d= eclare an alternative response from the =E2=80=9Ccontinue=E2=80=9D section = that=E2=80=99s defined today, which points to the GNPA continuation API. If= an extension defines some alternative way to deliver tokens, that could li= ve alongside a continuation API and the client could indicate support for i= t in its initial request.

    In any event, alternativ= e interaction and delivery methods are important, and even if we aren=E2=80= =99t going to support every last one of them directly, the protocol design = should at least be aware of them.

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

    On Feb 4, 2021, at 8:35 A= M, Fabien Imbault <fabien.imbault@gmail.com>= wrote:

    Hi Tom,=C2=A0

    Sur= e, any experience on that would be greatly appreciated, we're calling f= or help here (the point being that I suspect what they're doing is not = trivial).

    Fabien

    On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <t= homasclinganjones@gmail.com> wrote:
    I've had such an app working for over a year. Th= ere are issues which are being addressed by the browser Interaction team of= oidc.

    thx ..Tom (mobile)

    = On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault <fabien= .imbault@gmail.com> wrote:
    Hi Francis,=C2=A0

    I've tried a few thin= gs with regards to using the AS on a phone, but it's really quite=C2=A0= complex.=C2=A0

    Making that run on a phone comes wi= th quite a bit of trouble. The most difficult part if that we'd need to= use a secure element, but just installing and hosting a http server secure= ly is not a standard setup at all. I suggest interested people step in to w= ork on this, as we already have a lot of work for the (more usual) server c= ase and already handle a privacy preserving scheme.=C2=A0

    Please let us know what you think.

    Cheers,=
    Fabien=C2=A0

    On Tue, Nov 24= , 2020 at 5:55 AM Fabien Imbault <fabien= .imbault@gmail.com> wrote:
    Hi Francis,

    I've thought a bit more to what you said. I think I'll give it a t= ry as a separate experiment (in code, not in theory). Not that I would expe= ct it to be included in GNAP, but I kind of like the idea :-)

    The direct impact for GNAP would be t= o think about multiple ASs.=C2=A0

    Will let you know.=C2=A0

    Fabien=C2=A0


    Le mer. 18 nov. = 2020 =C3=A0 13:06, Francis Pouatcha <fpo@adorsys.d= e> a =C3=A9crit=C2=A0:
    It would be nice if the protocol was designed at many layers of = abstraction.

    • The first layer shall design abstra= ct protocol flows, without specification of the mode and mechanism of inter= action.
    • The second layer can instantiate the first layer for dedica= ted interaction. Here we can talk http, we can define interactions that pre= sume server based token generation, we can define interaction that run on u= ser device based token generation.
    This is also the fundament= of the structure I proposed for the spec (https://gith= ub.com/ietf-wg-gnap/gnap-core-protocol/issues/30).

    =
    /Francis

    = From:=C2=A0Fabien Imbault <fabien.imbault@gmail.com>
    Sent:=C2= =A0Wednesday, November 18, 2020 6:35 AM
    To:=C2=A0Francis Pouatcha <fpo@adorsys.de>
    Cc:=C2=A0    txa= uth@ietf.org=C2=A0<tx= auth@ietf.org>; Dick Hardt <dick.hardt@gmail.com>; Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer <= ;jricher@mit.edu>
    Subject:=C2=A0Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00<= /font>
    =C2=A0
    Would make sense, but no= t so easy as we rely heavily on HTTP. Hence the discussion about deep links= and so on.

    An alternative might be provided by wasm/was= i (running a local sandbox on your phone, for your own AS), but it's re= ally early stage. This also poses another question that Denis has put forwa= rd, i.e. how do we handle the multiple AS scenario (likely to occur then).= =C2=A0

    Fabien=C2=A0

    On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@adorsys.de> wrote:
    We are drifting away from the original problem space.
    • My original mention was about the "POST" request, th= at subsumes that the "AS" is a "Server". Designing a ne= w protocol, we cannot afford this limitation.
    • I just mentioned SIOP= to show a known and closed example? Let us not focus on the device local d= iscovery scheme (like openid:) for now.
    • As capability of holding pr= ivate keys on user device evolves, server-based issuing of token will be fa= ding out giving way to device local generation of token.
    Whil= e designing GNAP, let us assume the AS-Role can be exercised on a user devi= ce and design the protocol to honor that.

    Best reg= ards,
    /Francis
    From:=C2=A0TXAuth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
    Sent= :=C2=A0Tuesday, November 17, 2020 1:28 PM
    To:=C2=A0Tom Jones <thomasclinganjones@gmail.com>
    Cc:=C2=A0Fabi= en Imbault <fabien.imbault@gm= ail.com>; Denis <denis.ietf@= free.fr>; GNAP Mailing List <tx= auth@ietf.org>; Justin Richer <= jricher@mit.edu>
    Subject:=C2=A0Re: [GNAP] Rev= iew of draft-ietf-gnap-core-protocol-00
    =C2=A0
    <= div dir=3D"ltr">Got it.=C2=A0

    So web apps invoke a o= penid: deep link and hope there is an app to handle the openid: scheme? ...= and that it is the user's wallet rather than some malware that has reg= istered openid: on the mobile device?

    A native app= can attempt to open a deep link associated with an app, and will fail if t= he app is not there. If the app is there, it will be opened, so this can= 9;t be used to silently test if an app is present, but it does allow a nati= ve app to provide an alternative experience if an app is not present. I don= 't think this works with custom schemes ... and I don't know how it= could work from a web app on the phone with the current Safari APIs.
    =

    Apple warns against using custom schemes [1] ... but pe= rhaps they can be convinced to make openid: a managed scheme similar to mai= lto:, tel:, sms:, facetime: ?


    =

    3D""=E1=90=A7

    On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrot= e:
    You are - tha= t is not standard which is opeind://
    This is the one step that st= ill needs to be optimized for SIOP to have good UX.
    Peace ..tom

    <= /div>

    On Tue, Nov 17, 2020 at 9:59 AM Dick H= ardt <dick.hardt@gmail.com>= ; wrote:
    Hi Tom
    <= br>
    I watched your video (I watched at 2X speed)

    Looks like the employment website app that is using localhost:8765= to communicate with the wallet. Am I correct?

    /Di= ck=C2=A0
    3D""= =E1=90=A7

    On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
    <= /div>
    Well, here's a demo. = Note that in this case the AS is not online all of the time, so it is reall= y implicit flow and the OIDC id-token comes from the siop device directly.<= div>(whether this is front-channel or back channel is no longer an interest= ing question.)
    Now if an always-on AS is required, that is possible= , but probably beyond the scope of this effort and would require something = like an agent-in-the-sky=C2=A0(with diamonds).
    here is the link to the 9 min video=C2=A0=C2=A0=C2=A0https://= youtu.be/Tq4hw7X5SW0
    <= div dir=3D"ltr">
    Peace ..tom

    On Tue, Nov 17, 2020 at 9:20 = AM Justin Richer <jricher@mit.edu&= gt; wrote:
    Ultimately, in most si= tuations like these in the real world, the hurdle isn=E2=80=99t technical c= ompatibility so much as it is trust compatibility. The RP (client) needs to= have some incentive to trust the assertions and identity information that= =E2=80=99s coming from the AS. The same is true for an RS trusting tokens f= rom the AS. The hard question is less =E2=80=9Chow=E2=80=9D to do that (whi= ch SSI answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn= =E2=80=99t answer very well, because it=E2=80=99s a hard question).
    Still: it=E2=80=99s definitely a question about how to support = this =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of= it more than OAuth2/OIDC have by allowing the bootstrap of the process fro= m a starting call: the interaction and continuation URIs handed back by the= AS don=E2=80=99t need to be the same URIs that the client starts with, so = just like SIOP the process can start in HTTP and potentially move to other = communication channels. A major difference is that we aren=E2=80=99t depend= ent on the assumption that the user will always be in a browser at some sta= ge, and so the whole raft of front-channel messages that SIOP relies on doe= sn=E2=80=99t fly. That said, we=E2=80=99ve got an opportunity to more expli= citly open up alternative communication channels here, and that=E2=80=99s s= omething I=E2=80=99d like to see engineered, even if it=E2=80=99s an extens= ion. I=E2=80=99d love to see a concrete proposal as to how that would work = over specific protocols, starting with what we=E2=80=99ve got today.=C2=A0<= /div>

    =C2=A0=E2=80=94 Justin

    On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Denis, hi Francis,=C2=A0

    At some point integration with SSI (on the authentication side) will proba= bly occur, including amongst other possibilities SIOP (since they work with= OpenID a part of the work will probably be made easier).=C2=A0
    <= br>
    That being said, Denis is right. It's not an AS. Technica= lly it's entirely possible to rely on a decentralized wallet (for insta= nce on your phone) and a centralized AS. I know of a few studies on how to = decentralize the AS itself (for instance=C2=A0https://tools.ietf.org/html= /draft-hardjono-oauth-decentralized-02).
    Maybe it exists, but= I'm still looking for real scenarios (or even architectures) where an = AS is deployed directly on a phone, and under the sole authority of the RO,= while being compatible with the rest of the world.=C2=A0

    Cheers,
    Fabien

    On Tu= e, Nov 17, 2020 at 5:45 PM Denis <d= enis.ietf@free.fr> wrote:
    =
    Hello=C2=A0 Francis,

    See two comments in line= .


    B) Current Document

    Roles description shall n= ot hold any assumption on the physical structure of the party fulfilling th= e roles.
    [FI] not sure = what you mean
    =C2=A0[FP]= for example, we assume the AS is a server! In most SSI based use cases, th= e AS will be running on the user device. See SIOP (https://i= dentity.foundation/did-siop/).
    I browsed through the two= drafts, i.e. :
    • Decentralized Identifiers (DIDs) v1.0 Core arc= hitecture, data model, and representations W3C Working Draft 08 November 20= 20
    • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Workin= g Group Draft
    At n= o place within these two documents, it is possible to imagine that "th= e AS will be running on the user device".
    From section 3 of the DIF Working Group Draft:=
    =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.Core],= the SIOP will not return an access token to the RP".
    An Identity Wallet is not an AS.=C2=A0
    =

    Roles:=C2=A0
    -> grant endpoint of the AS: Why is this a post reque= st? This eliminates the chance of having user device hosted AS (no server).=
    [FI] what would you propose instead?
    Would also be interested to understand better the depl= oyment model when there is no server. That's something that was discuss= ed several times but I'm still missing the underlying architecture and = use case.
    =C2=A0[FP] See above (SIOP). There will = be a lot of identity wallets operated on end user device.
    =
    Se= e the above comment. Please, do not confuse an Identity Wallet with an Auth= entication Server (AS).
    Denis
    =
    =
    -> Resource Owner (RO) : Authorizes th= e request? Does it authorize the request or the access to a resource?
    =
    [FI] = yes, we should make the wording clearer

    =
    Missing Section Interactions:
    --> This section shall introduce the notion of interac= tion before we start listing interaction types.
    [FI] yes=C2=A0
    =

    Interaction Types:
    --> I prefer a classification with Redirect, Decoupl= ed and Embedded is. In the draft, we have one redirect and 2 decouple inter= actions and nothing else.
    [FI] this should be handled as a specific discuss= ion item. As a reminder, how would you define embedded?

    In practice there'= s at least these modes:
    - redirect and redirect back
    - redirect to different browser or device
    =
    - user code
    - CIBA
    [FP] This classification is limited.
    • Redirect: same device, same or different user agents (browser, m= obile app, desktop app, ...)
    • Decoupled: different devices
    • E= mbedded : RC carries RO authorization to AS


    Reso= urce Access Request vs. Resource Request
    --&= gt; Both are mixed up. No clarification of the context of each section.
    [FI= ] could you clarify what you'd expect.=C2=A0 Btw on this topic, there&#= 39;s a more general discussion on whether we should make a distinction or n= ot.=C2=A0
    [FP]: Here:
    • Resource Access Request: Requesting Access to a resource= . Response is an access token (or any type of grant)
    • Resource Request: Request the resource.= Response is the resource (or a corresponding execution)

    Token Content= Negotiation
    --> Not expressed as such. T= his is central to GNAP and not represented enough=C2=A0 in the document.
    [F= I] right. This should be a specific discussion item.=C2=A0

    Requesting "User&q= uot; Information
    we identify two types of us= ers: RQ and RO. It will be better not to refer to a user in this draft, but= either to a RQ or an RO.
    [FI] yes that would avoid potential misunderstand= ings. Although in the end, people will translate RQ into user=C2=A0or end-u= ser most of the time. Cf in definition, currently we have=C2=A0Requesting Party (RQ, aka "user")


    Interac= tion Again
    -> F= or each interaction type, we will have to describe the protocol flow and th= e nature and behavior of involved Roles (Parties), Elements, Requests.
    [FI] yes=C2=A0=C2=A0

    [FP] Will these and into tickets?

    =
    = Best regards.
    /Francis


    =
    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/tx= auth
    --=C2=A0
    TXAuth mailing list=
    TXAuth@ietf.org
    https://www.ietf.org/mailman/list= info/txauth

    --=C2=A0<= /span>
    TXAuth mailing list
    TXAuth@i= etf.org
    https://www.ietf.org/mailman/listinfo/txauth
    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth=

    --=C2=A0
    TXAu= th mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    =
    --=C2=A0
    TXAuth mailing = list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    --=C2= =A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txa= uth
    --0000000000000db01c05bad464cc-- From nobody Mon Feb 8 07:42:14 2021 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 7F96B3A0E93 for ; Mon, 8 Feb 2021 07:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Xs83cse8O8Ap for ; Mon, 8 Feb 2021 07:42:09 -0800 (PST) Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) (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 029A73A0E97 for ; Mon, 8 Feb 2021 07:42:08 -0800 (PST) Received: by mail-vk1-f170.google.com with SMTP id k1so3220277vkb.11 for ; Mon, 08 Feb 2021 07:42:08 -0800 (PST) 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=uYZhXidh69gJsvkvUoA4tFFheXfYf22sXYWUS5aB8h4=; b=EL3wG9/DMmNeF68Y2M2THvxjX5nI7IE/A3lNP07M6GV9UQ+oZHEZxXZJAPIuas65To wX5TWNhjzBtwv1bTxAjiAcAwlTY+neuSvu7L80kaiwXd7F2ugp+J/zhzEGQE2utrFpwq QqxhSyg8+kr6RV7TGmJCGxHdTH9cwGUiIM56/1vt7A+ymYertCBP/g6UEMLKB6Ck14f+ XCS4HStgGAsl+GCfV+mCQTXaNUCT53jnlvcjx3MdwmnQmdybN1V0OQV8rH7dr8ySMfPE beoalPIRw05fxexWQnBGudOJB9ve3d07zQgo1L9AMg2/AEZEtS8rmgbnMl69pw4vPLPw 094g== X-Gm-Message-State: AOAM531qA+gP9zWs5HS6pwErsNlaGx7/+G8GEdHOs6J2Bf5/yowO6eTR ZN6OBERzEcn1WRsWWrecnOtHyERsoqoVcXmxzz4= X-Google-Smtp-Source: ABdhPJzS2UWH8ehxuglfySH/LJoAPGE9w8CqxES2bsPlVC4YLv5y2SV+QvocB3xvsOer82IZoCjsxTnoj+DlPTdX5Ik= X-Received: by 2002:a1f:9692:: with SMTP id y140mr10244213vkd.20.1612798927681; Mon, 08 Feb 2021 07:42:07 -0800 (PST) MIME-Version: 1.0 References: <7A612194-5C4B-4658-B7F0-E6058D044255@mit.edu> In-Reply-To: From: Adrian Gropper Date: Mon, 8 Feb 2021 10:41:55 -0500 Message-ID: To: Fabien Imbault Cc: Tom Jones , Justin Richer , Francis Pouatcha , txauth gnap Content-Type: multipart/alternative; boundary="0000000000002dbe3805bad50344" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 15:42:14 -0000 --0000000000002dbe3805bad50344 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to keep a focus on HTTP and an eye to mobile. The COVID vaccination credentials use-case is prominent these days. This is my suggestion for that https://github.com/smart-on-fhir/health-cards/issues/59#issuecomment-775232= 188 Adrian On Mon, Feb 8, 2021 at 9:57 AM Fabien Imbault wrote: > +1 > The interim meeting planned on Wednesday will be a good opportunity to > discuss interactions ! > > Fabien > > On Mon, Feb 8, 2021 at 2:22 PM Tom Jones > wrote: > >> Justin +1 >> >> thx ..Tom (mobile) >> >> On Mon, Feb 8, 2021, 5:19 AM Justin Richer wrote: >> >>> I agree that the focus of this group does need to be on an HTTP-based A= S >>> =E2=80=94 this particular use case is the one that we have to solve for= , and that=E2=80=99s >>> why those details are called out in the charter. We aren=E2=80=99t here= to try to >>> build a transport-independent security language, with abstractions and >>> bindings and things of that sort. But that said, the =E2=80=9Con-device= AS=E2=80=9D use >>> case is being brought up a lot, and solutions have been hacked together= in >>> the OAuth 2 world in several different ways. As such, we as a WG should= be >>> paying attention to them, and if there are things we can do in our desi= gn >>> to allow for that kind of deployment then we need to consider them. Tha= t >>> doesn=E2=80=99t mean we have to have that fully specified in the core p= rotocol, but >>> if there=E2=80=99s a way to design this so that it can be extended in t= hat >>> direction without the kind of hacks that the OAuth 2 solutions have to = rely >>> on, then it=E2=80=99ll be better for everyone. This can=E2=80=99t distr= act us from solving >>> the core use cases, or drive us to making the core so complex that it >>> becomes irrelevant, but we shouldn=E2=80=99t be blind to these other po= ssibilities. >>> >>> In my opinion as a contributor, the best opportunities we have for that >>> kind of extension in the way the protocol=E2=80=99s built right now are= in the >>> interaction and continuation pieces of GNAP. Interaction we=E2=80=99ve = always known >>> was going to allow for a move off-browser, and less dependence on >>> user-in-a-browser is baked into the charter as well. But we need more >>> experience and more details about :how: that works, and that=E2=80=99s = a lot of >>> what this current conversation is going to be about. You are completely >>> right that there are another set of challenges, but in my mind it=E2=80= =99s that >>> the trust model is simply different. What do I trust more, a device in = my >>> pocket or a web server in someone else=E2=80=99s data center? There isn= =E2=80=99t an easy >>> or universal answer to that question, as it turns out. >>> >>> =E2=80=94 Justin >>> >>> On Feb 7, 2021, at 5:51 PM, Francis Pouatcha wrote: >>> >>> Hello Fabian, >>> >>> I am sorry for the delayed reply, but very busy working on those >>> decentralized use cases where tokens a produced on the user device. >>> >>> >>> Like we can see in this thread, it is not obvious to have those use >>> cases considered in GNAP (as the GNAP charter mentions reliance on HTTP >>> based AS). >>> >>> If the role of an AS is to produce an authorization, a user device >>> hosted AS can be build, but the negotiation process will be different f= rom >>> the one defined by GNAP. Means interaction protocol will need more than >>> just HTTP. >>> >>> The biggest challenge we are facing on user device produced auth tokens >>> is on how to preserve those crypto keys held on user device from malwar= e, >>> loss of device... >>> >>> For the moment keeping focus of GNAP on (http) server-based production >>> of token looks like a good decision. >>> >>> I will review the draft sometime as soon as possible and provide my >>> feedback. >>> >>> Best regards, >>> >>> /Francis >>> >>> ------------------------------ >>> *From:* TXAuth on behalf of Fabien Imbault < >>> fabien.imbault@gmail.com> >>> *Sent:* Friday, February 5, 2021 3:41 PM >>> *To:* Adrian Gropper >>> *Cc:* Tom Jones ; txauth gnap < >>> txauth@ietf.org>; Justin Richer >>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>> >>> Hi Adrian, >>> >>> We would be glad to get your expertise on that. Not sure DIDComm is >>> essential yet, so far I see it personally as something to look into, >>> especially for use cases when we want to reach out to a RO. I agree wit= h >>> the potential issues. >>> >>> I have a few ideas on how to implement privacy, but it's quite involved >>> in terms of crypto (again using Ristretto groups :-)). >>> >>> Of course there will be a question of priority in the features we plan >>> to implement. I guess we should aim for a first publication without the >>> parts which are blurry, and take the time to prototype the rest. >>> >>> Cheers >>> Fabien >>> >>> Le ven. 5 f=C3=A9vr. 2021 =C3=A0 21:19, Adrian Gropper a >>> =C3=A9crit : >>> >>> There are privacy implications as well as the cost of processing spam. = A >>> service endpoint associated with a DID can be presumed to be a public >>> broadcast. Any party can attempt to send a message or an authorization >>> request to that service endpoint. The operator of that service, typical= ly >>> the DID controller, will bear the cost and risk of processing the messa= ge. >>> They may request a bond be posted by the party responding to the >>> "broadcast" in order to mitigate spam and phishing. They may also requi= re >>> that the party seeking to communicate offer credentials, which poses a >>> privacy risk to that party in the form of phishing "broadcasts" via DID= s >>> and lures that lead to DIDs. >>> >>> In my role as invited expert on privacy to some W3C WGs and, to some >>> extent, DIF WGs, I have not managed to understand the privacy engineeri= ng >>> and implications in DIDcomm. I will try harder if DIDcomm has an essent= ial >>> role with GNAP and I can understand it in the self-sovereign or fiducia= ry >>> authorization server context. Does it? >>> >>> Adrian >>> >>> On Fri, Feb 5, 2021 at 1:08 PM Fabien Imbault >>> wrote: >>> >>> Probably (and to be honest even for industrial users I find it complex)= , >>> but alternatives are not ready for prime time either. >>> Maybe some day DIDComm could be useful as a basic block, what we sugges= t >>> is to first use that as a potential interaction (and there's already a = lot >>> of questions that arise just from that). >>> >>> Fabien >>> >>> On Fri, Feb 5, 2021 at 6:55 PM Tom Jones >>> wrote: >>> >>> No, you didn't misunderstand me. It's just that the ux for that is not >>> acceptable to retail users. As long as gnap sticks to industrial users = you >>> should do fine. >>> >>> thx ..Tom (mobile) >>> >>> On Fri, Feb 5, 2021, 7:56 AM Fabien Imbault >>> wrote: >>> >>> Targeting existing browsers and types of applications (web, pwa, mobile= , >>> etc.) seems like a reasonable option for an industrial standard. Improv= ing >>> security, privacy, ease of use and interoperability (including >>> decentralized identity as well) should be good enough objectives. >>> Plus from our previous discussions, I was under the impression you were >>> fine with the approach of deploying the AS on the phone as a loopback, = for >>> mobile apps. Did I miss something? >>> >>> Cheers, >>> Fabien >>> >>> Le ven. 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones >>> a =C3=A9crit : >>> >>> If you mean can GNAP work on old fashioned apps running with existing >>> browsers and existing identity providers, then yes, i guess you are ok. >>> >>> If you want to work on apps where the user is in control of authn and >>> authz, then no, GNAP cannot work. It is not alone in that OIDC wont wor= k >>> there either. >>> >>> Be the change you want to see in the world ..tom >>> >>> >>> On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault >>> wrote: >>> >>> Hi Tom, >>> >>> Thanks, your responses made it clearer for me what you expect from an A= S >>> deployed on a mobile. >>> >>> I think we're on the right path to meet the rest of your concerns. Ther= e >>> are already a few items on these: >>> - privacy preserving techniques have been discussed and are likely to b= e >>> included (I think). It's been recognized as a core concern >>> - not exactly sure the meaning you give to discovery here (it's already >>> been used in the WG but with a different meaning I believe). The reques= t or >>> the continuation api provide entry points to pay attention to. >>> >>> Is that enough for your use case ? Do you need something else ? (like >>> SSE?) >>> >>> Cheers >>> Fabien >>> >>> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom Jones >>> a =C3=A9crit : >>> >>> discovery is the prime problem. What causes the wallet/AS to wake up >>> and pay attention. How does the RP know what to ask for without violati= ng >>> user privacy rights? >>> >>> CHAPI would be ok i guess, but that requires cred man to be fixed. Not >>> sure if it fixes discovery or privacy even then. >>> >>> Be the change you want to see in the world ..tom >>> >>> >>> On Thu, Feb 4, 2021 at 12:45 PM Justin Richer wrote: >>> >>> Tom, what additional functionality do you see that a browser would need >>> to support in order for GNAP to be adopted? For the elements of the cor= e >>> protocol today, nothing is needed to change within the browsers =E2=80= =94 >>> everything is built on existing functions. GNAP uses browsers as a tool= , >>> and I would argue depends on them even less so than OAuth 2 does. >>> Extensions could use browser functionality, like using CHAPI to pass >>> interaction elements, but the core protocol functions on vanilla browse= rs >>> today. >>> >>> =E2=80=94 Justin >>> >>> On Feb 4, 2021, at 3:20 PM, Tom Jones >>> wrote: >>> >>> i assumed that the wallet (aka AS) needed to be a native app, not a PWA >>> (which can come from a traditional web server). >>> There are folks, lke Kim C, who are working on a PWA, but i agree the >>> blocks there seem to be large. >>> THe blocks on a native app are simple, easy to describe, and easy to as= k >>> the browser guys to fix. Not sure if they care tho. >>> I have trouble seeing a path to GNAP adoption for retail customers w/o >>> some browser support. >>> That's why i am mostly silent here. >>> >>> Be the change you want to see in the world ..tom >>> >>> >>> On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault >>> wrote: >>> >>> Fair enough. But loopback limits a lot what you can do... Just for debu= g >>> it's a pain. >>> But as soon as you try more, it's a bit crazy. Fun to test ipv6 (luckil= y >>> supported by my ISP) and ddns. But it feels really hacky. >>> Also deployment is a pain, compared to a traditional webserver. >>> >>> Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones >>> a =C3=A9crit : >>> >>> doesn't work very well on windows uwp. works fine on smartphones >>> Be the change you want to see in the world ..tom >>> >>> >>> On Thu, Feb 4, 2021 at 11:18 AM Justin Richer wrote: >>> >>> OK, thanks =E2=80=94 in that case, there are no changes at all to GNAP,= which is >>> already HTTP driven. The harder parts tend to be where you can=E2=80=99= t (or don=E2=80=99t >>> want to) use something like that. >>> >>> =E2=80=94 Justin >>> >>> On Feb 4, 2021, at 2:16 PM, Tom Jones >>> wrote: >>> >>> yes, loopback >>> >>> Be the change you want to see in the world ..tom >>> >>> >>> On Thu, Feb 4, 2021 at 11:01 AM Justin Richer wrote: >>> >>> Tom, can you expand on how exactly the back-channel communication work= s >>> between on-device components? Do you use HTTP locally? >>> >>> Thanks, >>> =E2=80=94 Justin >>> >>> On Feb 4, 2021, at 1:03 PM, Tom Jones >>> wrote: >>> >>> Justin's analysis of use of the front channel is misleading. >>> It could equally be argued that what i have done is installed an AS on >>> the phone and the communications with it & the PR is back channel. >>> Basically the point is that the old OIDC paradigms are no longer valid. >>> Be the change you want to see in the world ..tom >>> >>> >>> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault >>> wrote: >>> >>> Yes, issue (#168) message based interaction / DIDComm is a tentative >>> alternative mecanism for the interaction part. Not sure how that would = work >>> in details though, prototyping will probably help here. >>> Token delivery through continuation seems fine to me. The client will >>> probably have to wait for the next polling before it receives a token >>> issued as the result of an asynchronous interaction, but that's not a b= ig >>> issue. >>> >>> But the AS on the phone seems like a harder nut to crack, at least at >>> first sight. I think that would be awesome, but it gives me headaches, = so I >>> think I'll work on easier stuff right now ;-) >>> >>> Fabien >>> >>> On Thu, Feb 4, 2021 at 4:30 PM Justin Richer wrote: >>> >>> One of the biggest drawbacks of the current app-centric approaches in >>> OIDC (self-issued OP, or SIOP) is that they depend on using the front >>> channel and browser redirects to pass everything, which is something th= at >>> GNAP is deliberately getting away from by starting in the back channel. >>> >>> That said, once a request is kicked off in GNAP, the interaction and >>> fulfillment can happen through any number of means. Part of the work th= at=E2=80=99s >>> being done with the =E2=80=9Cinteraction=E2=80=9D section is going to h= elp facilitate this, >>> and I think that there are some other potential branches here. >>> >>> Token delivery is where things get extra weird though =E2=80=94 we are >>> explicitly not delivering tokens in the front channel in the core of GN= AP, >>> we=E2=80=99re using the response from the continuation API. One idea (t= hat isn=E2=80=99t >>> particularly well thought out and hasn=E2=80=99t been implemented at al= l) is to >>> have an extension declare an alternative response from the =E2=80=9Ccon= tinue=E2=80=9D >>> section that=E2=80=99s defined today, which points to the GNPA continua= tion API. If >>> an extension defines some alternative way to deliver tokens, that could >>> live alongside a continuation API and the client could indicate support= for >>> it in its initial request. >>> >>> In any event, alternative interaction and delivery methods are >>> important, and even if we aren=E2=80=99t going to support every last on= e of them >>> directly, the protocol design should at least be aware of them. >>> >>> =E2=80=94 Justin >>> >>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault >>> wrote: >>> >>> Hi Tom, >>> >>> Sure, any experience on that would be greatly appreciated, we're callin= g >>> for help here (the point being that I suspect what they're doing is not >>> trivial). >>> >>> Fabien >>> >>> On Thu, Feb 4, 2021 at 2:21 PM Tom Jones >>> wrote: >>> >>> I've had such an app working for over a year. There are issues which ar= e >>> being addressed by the browser Interaction team of oidc. >>> >>> thx ..Tom (mobile) >>> >>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault >>> wrote: >>> >>> Hi Francis, >>> >>> I've tried a few things with regards to using the AS on a phone, but >>> it's really quite complex. >>> >>> Making that run on a phone comes with quite a bit of trouble. The most >>> difficult part if that we'd need to use a secure element, but just >>> installing and hosting a http server securely is not a standard setup a= t >>> all. I suggest interested people step in to work on this, as we already >>> have a lot of work for the (more usual) server case and already handle = a >>> privacy preserving scheme. >>> >>> Please let us know what you think. >>> >>> Cheers, >>> Fabien >>> >>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault >>> wrote: >>> >>> Hi Francis, >>> >>> I've thought a bit more to what you said. I think I'll give it a try as >>> a separate experiment (in code, not in theory). Not that I would expect= it >>> to be included in GNAP, but I kind of like the idea :-) >>> >>> The direct impact for GNAP would be to think about multiple ASs. >>> >>> Will let you know. >>> >>> Fabien >>> >>> >>> Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha a >>> =C3=A9crit : >>> >>> It would be nice if the protocol was designed at many layers of >>> abstraction. >>> >>> >>> - The first layer shall design abstract protocol flows, without >>> specification of the mode and mechanism of interaction. >>> - The second layer can instantiate the first layer for dedicated >>> interaction. Here we can talk http, we can define interactions that = presume >>> server based token generation, we can define interaction that run on= user >>> device based token generation. >>> >>> This is also the fundament of the structure I proposed for the spec ( >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). >>> >>> /Francis >>> >>> ------------------------------ >>> *From:* Fabien Imbault >>> *Sent:* Wednesday, November 18, 2020 6:35 AM >>> *To:* Francis Pouatcha >>> *Cc:* txauth@ietf.org ; Dick Hardt < >>> dick.hardt@gmail.com>; Tom Jones ; Denis = < >>> denis.ietf@free.fr>; Justin Richer >>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>> >>> Would make sense, but not so easy as we rely heavily on HTTP. Hence the >>> discussion about deep links and so on. >>> >>> An alternative might be provided by wasm/wasi (running a local sandbox >>> on your phone, for your own AS), but it's really early stage. This also >>> poses another question that Denis has put forward, i.e. how do we handl= e >>> the multiple AS scenario (likely to occur then). >>> >>> Fabien >>> >>> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha >>> wrote: >>> >>> We are drifting away from the original problem space. >>> >>> - My original mention was about the "POST" request, that subsumes >>> that the "AS" is a "Server". Designing a new protocol, we cannot aff= ord >>> this limitation. >>> - I just mentioned SIOP to show a known and closed example? Let us >>> not focus on the device local discovery scheme (like openid:) for no= w. >>> - As capability of holding private keys on user device evolves, >>> server-based issuing of token will be fading out giving way to devic= e local >>> generation of token. >>> >>> While designing GNAP, let us assume the AS-Role can be exercised on a >>> user device and design the protocol to honor that. >>> >>> Best regards, >>> /Francis >>> ------------------------------ >>> *From:* TXAuth on behalf of Dick Hardt < >>> dick.hardt@gmail.com> >>> *Sent:* Tuesday, November 17, 2020 1:28 PM >>> *To:* Tom Jones >>> *Cc:* Fabien Imbault ; Denis < >>> denis.ietf@free.fr>; GNAP Mailing List ; Justin Richer >>> >>> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >>> >>> Got it. >>> >>> So web apps invoke a openid: deep link and hope there is an app to >>> handle the openid: scheme? ... and that it is the user's wallet rather = than >>> some malware that has registered openid: on the mobile device? >>> >>> A native app can attempt to open a deep link associated with an app, an= d >>> will fail if the app is not there. If the app is there, it will be open= ed, >>> so this can't be used to silently test if an app is present, but it doe= s >>> allow a native app to provide an alternative experience if an app is no= t >>> present. I don't think this works with custom schemes ... and I don't k= now >>> how it could work from a web app on the phone with the current Safari A= PIs. >>> >>> Apple warns against using custom schemes [1] ... but perhaps they can b= e >>> convinced to make openid: a managed scheme similar to mailto:, tel:, >>> sms:, facetime: ? >>> >>> [1] >>> https://developer.apple.com/documentation/xcode/allowing_apps_and_websi= tes_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app >>> >>> >>> =E1=90=A7 >>> >>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones >>> wrote: >>> >>> You are - that is not standard which is opeind:// >>> This is the one step that still needs to be optimized for SIOP to have >>> good UX. >>> Peace ..tom >>> >>> >>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt wrote= : >>> >>> Hi Tom >>> >>> I watched your video (I watched at 2X speed) >>> >>> Looks like the employment website app that is using localhost:8765 to >>> communicate with the wallet. Am I correct? >>> >>> /Dick >>> =E1=90=A7 >>> >>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones >>> wrote: >>> >>> Well, here's a demo. Note that in this case the AS is not online all of >>> the time, so it is really implicit flow and the OIDC id-token comes fro= m >>> the siop device directly. >>> (whether this is front-channel or back channel is no longer an >>> interesting question.) >>> Now if an always-on AS is required, that is possible, but probably >>> beyond the scope of this effort and would require something like an >>> agent-in-the-sky (with diamonds). >>> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 >>> >>> Peace ..tom >>> >>> >>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: >>> >>> Ultimately, in most situations like these in the real world, the hurdle >>> isn=E2=80=99t technical compatibility so much as it is trust compatibil= ity. The RP >>> (client) needs to have some incentive to trust the assertions and ident= ity >>> information that=E2=80=99s coming from the AS. The same is true for an = RS trusting >>> tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to = do that (which SSI >>> answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, >>> because it=E2=80=99s a hard question). >>> >>> Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on >>> device=E2=80=9D element. We=E2=80=99ve got the start of it more than OA= uth2/OIDC have by >>> allowing the bootstrap of the process from a starting call: the interac= tion >>> and continuation URIs handed back by the AS don=E2=80=99t need to be th= e same URIs >>> that the client starts with, so just like SIOP the process can start in >>> HTTP and potentially move to other communication channels. A major >>> difference is that we aren=E2=80=99t dependent on the assumption that t= he user will >>> always be in a browser at some stage, and so the whole raft of >>> front-channel messages that SIOP relies on doesn=E2=80=99t fly. That sa= id, we=E2=80=99ve >>> got an opportunity to more explicitly open up alternative communication >>> channels here, and that=E2=80=99s something I=E2=80=99d like to see eng= ineered, even if >>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete proposal = as to how that would >>> work over specific protocols, starting with what we=E2=80=99ve got toda= y. >>> >>> =E2=80=94 Justin >>> >>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault >>> wrote: >>> >>> Hi Denis, hi Francis, >>> >>> At some point integration with SSI (on the authentication side) will >>> probably occur, including amongst other possibilities SIOP (since they = work >>> with OpenID a part of the work will probably be made easier). >>> >>> That being said, Denis is right. It's not an AS. Technically it's >>> entirely possible to rely on a decentralized wallet (for instance on yo= ur >>> phone) and a centralized AS. I know of a few studies on how to decentra= lize >>> the AS itself (for instance >>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >>> Maybe it exists, but I'm still looking for real scenarios (or even >>> architectures) where an AS is deployed directly on a phone, and under t= he >>> sole authority of the RO, while being compatible with the rest of the >>> world. >>> >>> Cheers, >>> Fabien >>> >>> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >>> >>> Hello Francis, >>> >>> See two comments in line. >>> >>> >>> B) Current Document >>> >>> Roles description shall not hold any assumption on the physical >>> structure of the party fulfilling the roles. >>> [FI] not sure what you mean >>> >>> [FP] for example, we assume the AS is a server! In most SSI based use >>> cases, the AS will be running on the user device. See SIOP ( >>> https://identity.foundation/did-siop/). >>> >>> I browsed through the two drafts, i.e. : >>> >>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >>> model, and representations W3C Working Draft 08 November 2020 >>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working >>> Group Draft >>> >>> At no place within these two documents, it is possible to imagine that >>> "the AS will be running on the user device". >>> From section 3 of the DIF Working Group Draft: >>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the >>> SIOP will not return an access token to the RP". >>> An Identity Wallet is not an AS. >>> >>> >>> Roles: >>> -> grant endpoint of the AS: Why is this a post request? This eliminate= s >>> the chance of having user device hosted AS (no server). >>> [FI] what would you propose instead? >>> Would also be interested to understand better the deployment model when >>> there is no server. That's something that was discussed several times b= ut >>> I'm still missing the underlying architecture and use case. >>> >>> [FP] See above (SIOP). There will be a lot of identity wallets operate= d >>> on end user device. >>> >>> See the above comment. Please, do not confuse an Identity Wallet with a= n >>> Authentication Server (AS). >>> Denis >>> >>> >>> -> Resource Owner (RO) : Authorizes the request? Does it authorize the >>> request or the access to a resource? >>> [FI] yes, we should make the wording clearer >>> >>> Missing Section Interactions: >>> --> This section shall introduce the notion of interaction before we >>> start listing interaction types. >>> [FI] yes >>> >>> Interaction Types: >>> --> I prefer a classification with Redirect, Decoupled and Embedded is. >>> In the draft, we have one redirect and 2 decouple interactions and noth= ing >>> else. >>> [FI] this should be handled as a specific discussion item. As a >>> reminder, how would you define embedded? >>> >>> In practice there's at least these modes: >>> - redirect and redirect back >>> - redirect to different browser or device >>> - user code >>> - CIBA >>> >>> [FP] This classification is limited. >>> >>> - Redirect: same device, same or different user agents (browser, >>> mobile app, desktop app, ...) >>> - Decoupled: different devices >>> - Embedded : RC carries RO authorization to AS >>> >>> >>> >>> Resource Access Request vs. Resource Request >>> --> Both are mixed up. No clarification of the context of each section. >>> [FI] could you clarify what you'd expect. Btw on this topic, there's a >>> more general discussion on whether we should make a distinction or not. >>> >>> [FP]: Here: >>> >>> - Resource Access Request: Requesting Access to a resource. Response >>> is an access token (or any type of grant) >>> - Resource Request: Request the resource. Response is the resource >>> (or a corresponding execution) >>> >>> >>> Token Content Negotiation >>> --> Not expressed as such. This is central to GNAP and not represented >>> enough in the document. >>> [FI] right. This should be a specific discussion item. >>> >>> Requesting "User" Information >>> we identify two types of users: RQ and RO. It will be better not to >>> refer to a user in this draft, but either to a RQ or an RO. >>> [FI] yes that would avoid potential misunderstandings. Although in the >>> end, people will translate RQ into user or end-user most of the time. C= f in >>> definition, currently we have Requesting Party (RQ, aka "user") >>> >>> >>> Interaction Again >>> -> For each interaction type, we will have to describe the protocol flo= w >>> and the nature and behavior of involved Roles (Parties), Elements, Requ= ests. >>> [FI] yes >>> >>> >>> [FP] Will these and into tickets? >>> >>> Best regards. >>> /Francis >>> >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> --0000000000002dbe3805bad50344 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    +1 to keep a focus on HTTP and an eye to = mobile. The COVID vaccination credentials use-case is prominent these days.= This is my suggestion for that=C2=A0https://github.com/sma= rt-on-fhir/health-cards/issues/59#issuecomment-775232188

    Adrian

    On Mon, Feb 8, 2021 at 9:57 AM Fabie= n Imbault <fabien.imbault@gm= ail.com> wrote:
    +1=C2=A0<= br>
    The interim meeting planned on Wednesday will be a good opportunity= to discuss interactions !

    Fabien

    <= div class=3D"gmail_quote">
    On Mon, Feb= 8, 2021 at 2:22 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
    Justin +1

    thx ..Tom (mobi= le)

    On Mon, Feb 8, 2021, 5:19 AM Justin Richer <jricher@mit.edu> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
    I agree that the focus of this group does need to be o= n an HTTP-based AS =E2=80=94 this particular use case is the one that we ha= ve to solve for, and that=E2=80=99s why those details are called out in the= charter. We aren=E2=80=99t here to try to build a transport-independent se= curity language, with abstractions and bindings and things of that sort. Bu= t that said, the =E2=80=9Con-device AS=E2=80=9D use case is being brought u= p a lot, and solutions have been hacked together in the OAuth 2 world in se= veral different ways. As such, we as a WG should be paying attention to the= m, and if there are things we can do in our design to allow for that kind o= f deployment then we need to consider them. That doesn=E2=80=99t mean we ha= ve to have that fully specified in the core protocol, but if there=E2=80=99= s a way to design this so that it can be extended in that direction without= the kind of hacks that the OAuth 2 solutions have to rely on, then it=E2= =80=99ll be better for everyone. This can=E2=80=99t distract us from solvin= g the core use cases, or drive us to making the core so complex that it bec= omes irrelevant, but we shouldn=E2=80=99t be blind to these other possibili= ties.

    In my opinion as a contributor, the best opportuni= ties we have for that kind of extension in the way the protocol=E2=80=99s b= uilt right now are in the interaction and continuation pieces of GNAP. Inte= raction we=E2=80=99ve always known was going to allow for a move off-browse= r, and less dependence on user-in-a-browser is baked into the charter as we= ll. But we need more experience and more details about :how: that works, an= d that=E2=80=99s a lot of what this current conversation is going to be abo= ut. You are completely right that there are another set of challenges, but = in my mind it=E2=80=99s that the trust model is simply different. What do I= trust more, a device in my pocket or a web server in someone else=E2=80=99= s data center? There isn=E2=80=99t an easy or universal answer to that ques= tion, as it turns out.

    =C2=A0=E2=80=94 Justin

    On Feb 7, 2021, at 5:51 PM, Francis Po= uatcha <fpo@adorsys.de> wrote:

    Hello Fabian,

    I am so= rry for the delayed reply, but very busy working on those decentralized use= cases where tokens a produced on the user device.


    Like we can= see in this thread, it is not obvious to have those use cases considered i= n GNAP (as the GNAP charter mentions reliance on HTTP based AS).

    If the role of an AS is to produce an authorization, = a user device hosted AS can be build, but the negotiation process will be d= ifferent from the one defined by GNAP. Means interaction protocol will need= more than just HTTP.
    The biggest challenge= we are facing on user device produced auth tokens is on how to preserve th= ose crypto keys held on user device from malware, loss of device...

    For the moment keeping focus of GNAP on (http) ser= ver-based production of token looks like a good decision.

    I will review the draft sometime as soon as possible and p= rovide my feedback.

    =
    Best regards,

    /Francis

    From:= =C2=A0TXAuth <txauth-bounces@ietf.org> on b= ehalf of Fabien Imbault <fabien.imbault@gmail.com>
    Se= nt:=C2=A0Friday, February 5, 2021 3:41 PM
    To:=C2=A0Adrian Gropper <agropper@healthurl.com>
    Cc:=C2=A0Tom Jones <thomasclinganjones@gmail= .com>; txauth gnap <txauth@ietf.org>; Justin Richer <jricher@= mit.edu>
    Subject:=C2=A0Re: [GNAP] Review of d= raft-ietf-gnap-core-protocol-00
    =C2=A0
    Hi Adrian,

    We would be glad to get your expertise on that. Not sure DIDComm is e= ssential yet, so far I see it personally as something to look into, especia= lly for use cases when we want to reach out to a RO. I agree with the poten= tial issues.=C2=A0

    I hav= e a few ideas on how to implement privacy, but it's quite involved in t= erms of crypto (again using Ristretto groups :-)).
    <= br>
    Of course there will be a question of priority i= n the features we plan to implement. I guess we should aim for a first publ= ication without the parts which are blurry, and take the time to prototype = the rest.=C2=A0

    Cheers
    Fabien=C2=A0

    Le = ven. 5 f=C3=A9vr. 2021 =C3=A0 21:19, Adrian Gropper <agropper@health= url.com> a =C3=A9crit=C2=A0:
    There are privacy = implications as well as the cost of processing spam. A service endpoint ass= ociated with a DID can be presumed to be a public broadcast. Any party can = attempt to send a message or an authorization request to that service endpo= int. The operator of that service, typically the DID controller, will bear = the cost and risk of processing the message. They may request a bond be pos= ted by the party responding to the "broadcast" in order to mitiga= te spam and phishing. They may also require that the party seeking to commu= nicate offer credentials, which poses a privacy risk to that party in the f= orm of phishing "broadcasts" via DIDs and lures that lead to DIDs= .=C2=A0

    In my role as invited expert on privacy to some = W3C WGs and, to some extent, DIF WGs, I have not managed to understand the = privacy engineering and implications in DIDcomm. I will try harder if DIDco= mm has an essential role with GNAP and I can understand it in the self-sove= reign or fiduciary authorization server context. Does it?

    Adrian

    On Fri, Feb 5, 2021 at = 1:08 PM Fabien Imbault <fabien.imbault@gmail.com&g= t; wrote:
    Probably (and to be honest even for industri= al users I find it complex), but alternatives are not ready for prime time = either.=C2=A0
    Maybe some day=C2=A0DIDComm could be useful as a basic bl= ock, what we suggest is to first use that as a potential interaction (and t= here's already a lot of questions that arise just from that).=C2=A0

    Fabien

    On Fri, F= eb 5, 2021 at 6:55 PM Tom Jones <thomasclinganjones= @gmail.com> wrote:
    No, you didn't misunder= stand me. It's just that the ux for that is not acceptable to retail us= ers. As long as gnap sticks to industrial users you should do fine.

    =
    thx ..Tom (mobile)

    On Fri, Feb 5,= 2021, 7:56 AM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    Targeting exist= ing browsers and types of applications (web, pwa, mobile, etc.) seems like = a reasonable option for an industrial standard. Improving security, privacy= , ease of use and interoperability (including decentralized identity as wel= l) should be good enough objectives.=C2=A0
    Plus from our previous= discussions, I was under the impression you were fine with the approach of= deploying the AS on the phone as a loopback, for mobile apps. Did I miss s= omething?

    Cheers,
    Fabien

    Le ven. 5 f=C3=A9vr. 2= 021 =C3=A0 16:33, Tom Jones <thomascling= anjones@gmail.com> a =C3=A9crit=C2=A0:
    If = you mean can GNAP work on old fashioned apps running with existing browsers= and existing identity providers, then yes, i guess you are ok.
    <= br>
    If you want to work on apps where the user is in control of a= uthn and authz, then no, GNAP cannot work. It is not alone in that OIDC won= t work there either.

    Be the change you want to see in the world ..tom


    On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Tom,=C2=A0

    Thanks, your responses made it clearer for me = what you expect from an AS deployed on a mobile.=C2=A0

    I think we're on the right path to meet = the rest of your concerns. There are already a few items on these:
    - privacy preserving techniques have been discussed and are = likely to be included (I think). It's been recognized as a core concern= =C2=A0
    - not exactly sure the meaning you give to di= scovery here (it's already been used in the WG but with a different mea= ning I believe). The request or the continuation api provide entry points t= o pay attention to.=C2=A0

    Is that eno= ugh for your use case ? Do you need something else ? (like SSE?)

    Cheers
    Fabi= en=C2=A0

    Le jeu. 4 f=C3=A9vr. 2= 021 =C3=A0 22:10, Tom Jones <thomascli= nganjones@gmail.com> a =C3=A9crit=C2=A0:
    disco= very is the prime problem.=C2=A0 What causes the wallet/AS to wake up and p= ay attention. How does the RP know what to ask for without violating user p= rivacy rights?

    CHAPI would be ok i guess, but that requi= res cred man to be fixed. Not sure if it fixes discovery or privacy even th= en.

    <= span style=3D"background-color:rgb(242,242,242);font-size:14px;white-space:= pre-wrap">Be the change you want to see in the world ..tom


    On Thu, Feb 4, 2021 at 12:45 PM Justin Richer <jricher@mit.edu> wrote:
    Tom, what additio= nal functionality do you see that a browser would need to support in order = for GNAP to be adopted? For the elements of the core protocol today, nothin= g is needed to change within the browsers =E2=80=94 everything is built on = existing functions. GNAP uses browsers as a tool, and I would argue depends= on them even less so than OAuth 2 does. Extensions could use browser funct= ionality, like using CHAPI to pass interaction elements, but the core proto= col functions on vanilla browsers today.

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

    On Feb 4, 2021, at 3:20 = PM, Tom Jones <thomasclinga= njones@gmail.com> wrote:

    i assumed th= at the wallet (aka AS) needed to be a native app, not a PWA (which can come= from a traditional web server).
    There are folks, lke Kim C, who are wo= rking on a PWA, but i agree the blocks there seem to be large.
    TH= e blocks on a native app are simple, easy to describe, and easy to ask the = browser guys to fix. Not sure if they care tho.
    I have trouble se= eing a path to GNAP adoption for retail customers w/o some browser support.=
    That's why i am mostly=C2=A0silent here.

    Be the chan= ge you want to see in the world ..tom


    On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Fair enough. But loopback limits a lot what you can do... Just for d= ebug it's a pain.=C2=A0
    But as soon as you try more, i= t's a bit crazy. Fun to test ipv6 (luckily supported by my ISP) and ddn= s. But it feels really hacky.=C2=A0
    Also deployment = is a pain, compared to a traditional webserver.=C2=A0

    <= div dir=3D"ltr">Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit=C2=A0:
    =
    doesn't work very well on windows uwp. works fine on smartp= hones
    Be the change you want to see in the world ..tom


    On Thu, Feb 4, 2021 at 11:18 AM Justin Richer <jricher@mi= t.edu> wrote:
    OK, thanks =E2=80=94 in that case, there are = no changes at all to GNAP, which is already HTTP driven. The harder parts t= end to be where you can=E2=80=99t (or don=E2=80=99t want to) use something = like that.

    =C2=A0=E2=80=94 Justin

    On Feb 4, 2021, at 2:16 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

    yes, loopback

    Be the change you want to see in the w= orld ..tom


    On Thu, Feb 4, 2021 at 11:01 AM Justin Richer <jricher@mi= t.edu> wrote:
    Tom, can you expand on how exactly the back-c= hannel =C2=A0communication works between on-device components? Do you use H= TTP locally?

    Thanks,
    =C2=A0=E2=80=94 Justin

    On Feb 4, 2021, at 1:03 PM, Tom Jo= nes <thomasclinganjones@gmail.com> wrote= :

    Justin's analysis of use of the front = channel is misleading.
    It could equally be argued that what i have done= is installed an AS on the phone and the communications with it & the P= R is back channel.
    Basically the point is that the old OIDC parad= igms are no longer valid.
    Be the change you want to see in the world ..tom


    On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault <f= abien.imbault@gmail.com> wrote:
    Yes, issue (#16= 8)=C2=A0message based interaction / DIDComm is a tentative alternative meca= nism for the interaction part. Not sure how that would work in details=C2= =A0though, prototyping will probably help here.
    Token delivery=C2=A0thr= ough continuation seems fine to me. The client will probably have to wait f= or the next polling before it receives a token issued as the result of an a= synchronous interaction, but that's not a big issue.

    But the AS on the phone seems like a harder nut to crack, at least a= t first sight. I think that would be awesome, but it gives me headaches, so= I think I'll work on easier stuff right now ;-)

    Fabien=C2=A0=C2=A0

    On Thu, Feb = 4, 2021 at 4:30 PM Justin Richer <jricher@mit.edu> wr= ote:
    One of the biggest drawbacks of the current app-centric appro= aches in OIDC (self-issued OP, or SIOP) is that they depend on using the fr= ont channel and browser redirects to pass everything, which is something th= at GNAP is deliberately getting away from by starting in the back channel.<= div>
    That said, once a request is kicked off in GNAP, the int= eraction and fulfillment can happen through any number of means. Part of th= e work that=E2=80=99s being done with the =E2=80=9Cinteraction=E2=80=9D sec= tion is going to help facilitate this, and I think that there are some othe= r potential branches here.

    Token delivery is where= things get extra weird though =E2=80=94 we are explicitly not delivering t= okens in the front channel in the core of GNAP, we=E2=80=99re using the res= ponse from the continuation API. One idea (that isn=E2=80=99t particularly = well thought out and hasn=E2=80=99t been implemented at all) is to have an = extension declare an alternative response from the =E2=80=9Ccontinue=E2=80= =9D section that=E2=80=99s defined today, which points to the GNPA continua= tion API. If an extension defines some alternative way to deliver tokens, t= hat could live alongside a continuation API and the client could indicate s= upport for it in its initial request.

    In any event= , alternative interaction and delivery methods are important, and even if w= e aren=E2=80=99t going to support every last one of them directly, the prot= ocol design should at least be aware of them.

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

    On Feb 4, 20= 21, at 8:35 AM, Fabien Imbault <fabien.imbault@gmai= l.com> wrote:

    Hi Tom,=C2=A0

    <= /div>
    Sure, any experience on that would be greatly appreciated, we'= ;re calling for help here (the point being that I suspect what they're = doing is not trivial).

    Fabien

    =
    On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
    I've had such an app working for over a year. There are issues which= are being addressed by the browser Interaction team of oidc.

    t= hx ..Tom (mobile)


    Hi Francis,

    I've= thought a bit more to what you said. I think I'll give it a try as a s= eparate experiment (in code, not in theory). Not that I would expect it to = be included in GNAP, but I kind of like the idea :-)

    The direct impact for GNAP would be to think a= bout multiple ASs.=C2=A0

    Will let you know.=C2=A0

    Fabien=C2=A0


    Le mer. 18 nov. 2020 =C3= =A0 13:06, Francis Pouatcha <fpo@adorsys.de>= ; a =C3=A9crit=C2=A0:
    It would be nice if the protoc= ol was designed at many layers of abstraction.

    • = The first layer shall design abstract protocol flows, without specification= of the mode and mechanism of interaction.
    • The second layer can ins= tantiate the first layer for dedicated interaction. Here we can talk http, = we can define interactions that presume server based token generation, we c= an define interaction that run on user device based token generation.
      • <= /ul>
      This is also the fundament of the structure I proposed for the spe= c (https://github.com/ietf-w= g-gnap/gnap-core-protocol/issues/30).

      /Francis=
    <= div style=3D"font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt"= >
    From:=C2=A0Fab= ien Imbault <fabien.imbault@g= mail.com>
    Sent:=C2=A0Wednesday, November 18, = 2020 6:35 AM
    To:=C2=A0Francis Pouatcha <fpo@adorsys.de>
    Cc:=C2=A0<= /span>txauth@ietf.org=C2=A0<txauth@ietf.org>; Dick Hard= t <dick.hardt@gmail.com>; = Tom Jones <thomasclinganj= ones@gmail.com>; Denis <deni= s.ietf@free.fr>; Justin Richer <jricher@mit.edu>
    Subject:=C2=A0Re: [GNAP] Re= view of draft-ietf-gnap-core-protocol-00
    =C2=A0
    =
    Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

    An = alternative might be provided by wasm/wasi (running a local sandbox on your= phone, for your own AS), but it's really early stage. This also poses = another question that Denis has put forward, i.e. how do we handle the mult= iple AS scenario (likely to occur then).=C2=A0

    Fab= ien=C2=A0

    On Wed, Nov 18, 2020 at 12:1= 6 PM Francis Pouatcha <fpo@adorsys.de> wrote:
    From:=C2=A0TXAuth <txau= th-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
    Sent:=C2= =A0Tuesday, November 17, 2020 1:28 PM
    To:=C2=A0Tom Jones <thomasclinga= njones@gmail.com>
    Cc:=C2=A0Fabien Imbault <= ;fabien.imbault@gmail.com>= ;; Denis <denis.ietf@free.fr>= ;; GNAP Mailing List <txauth@ietf.org<= /a>>; Justin Richer <jricher@mit.ed= u>
    Subject:=C2=A0Re: [GNAP] Review of draft-i= etf-gnap-core-protocol-00
    =C2=A0
    Got it.=C2=A0

    So web apps invoke a openid: deep li= nk and hope there is an app to handle the openid: scheme? ... and that it i= s the user's wallet rather than some malware that has registered openid= : on the mobile device?

    A native app can attempt t= o open a deep link associated with an app, and will fail if the app is not = there. If the app is there, it will be opened, so this can't be used to= silently test if an app is present, but it does allow a native app to prov= ide an alternative experience if an app is not present. I don't think t= his works with custom schemes ... and I don't know how it could work fr= om a web app on the phone with the current Safari APIs.

    Apple warns against using custom schemes [1] ... but perhaps they can= be convinced to make openid: a managed scheme similar to mailto:, tel:, sm= s:, facetime: ?


    =E1=90=A7

    On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
    You are - that is not standard which is opeind://
    = This is the one step that still needs to be optimized for SIOP to have good= UX.
    Peace ..tom<= /div>


    On Tue, No= v 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
    Hi Tom

    I watched your video (I watched at 2X speed)

    <= div>Looks like the employment website app that is using localhost:8765 to c= ommunicate with the wallet. Am I correct?

    /Dick=C2= =A0
    =E1=90=A7

    On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
    <= blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l= eft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
    Well, here's a demo. Note that in this case the AS is not on= line all of the time, so it is really implicit flow and the OIDC id-token c= omes from the siop device directly.
    (whether this is front-channel or b= ack channel is no longer an interesting question.)
    Now if an always= -on AS is required, that is possible, but probably beyond the scope of this= effort and would require something like an agent-in-the-sky=C2=A0(with dia= monds).
    here is the link to the 9 = min video=C2=A0=C2=A0=C2=A0https://youtu.be/Tq4hw7X5SW= 0
    P= eace ..tom


    On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
    Ultimately, in mo= st situations like these in the real world, the hurdle isn=E2=80=99t techni= cal compatibility so much as it is trust compatibility. The RP (client) nee= ds to have some incentive to trust the assertions and identity information = that=E2=80=99s coming from the AS. The same is true for an RS trusting toke= ns from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to do that = (which SSI answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI d= oesn=E2=80=99t answer very well, because it=E2=80=99s a hard question).
    Still: it=E2=80=99s definitely a question about how to supp= ort this =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the star= t of it more than OAuth2/OIDC have by allowing the bootstrap of the process= from a starting call: the interaction and continuation URIs handed back by= the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some= stage, and so the whole raft of front-channel messages that SIOP relies on= doesn=E2=80=99t fly. That said, we=E2=80=99ve got an opportunity to more e= xplicitly open up alternative communication channels here, and that=E2=80= =99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an = extension. I=E2=80=99d love to see a concrete proposal as to how that would= work over specific protocols, starting with what we=E2=80=99ve got today.= =C2=A0

    =C2=A0=E2=80=94 Justin

    On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> wr= ote:

    Hi Denis, hi Francis,=C2=A0

    At some point integration with SSI (on the authentication side) wil= l probably occur, including amongst other possibilities SIOP (since they wo= rk with OpenID a part of the work will probably be made easier).=C2=A0

    That being said, Denis is right. It's not an AS. T= echnically it's entirely possible to rely on a decentralized wallet (fo= r instance on your phone) and a centralized AS. I know of a few studies on = how to decentralize the AS itself (for instance=C2=A0https://tools.ietf.o= rg/html/draft-hardjono-oauth-decentralized-02).
    Maybe it exis= ts, but I'm still looking for real scenarios (or even architectures) wh= ere an AS is deployed directly on a phone, and under the sole authority of = the RO, while being compatible with the rest of the world.=C2=A0
    =
    Cheers,
    Fabien

    On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
    Hello=C2=A0 Francis,<= /div>

    See two comments in line.


    B) Current Document

    Roles description shall not hold any assumption on = the physical structure of the party fulfilling the roles.
    [FI] not sure what you mean
    =C2=A0[FP] for example, we assume the= AS is a server! In most SSI based use cases, the AS will be running on the= user device. See SIOP (https://identity.foundation/did-siop= /).
    I browsed through the two drafts, i.e. :
      Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and = representations W3C Working Draft 08 November 2020
    • Self-Issued Open= ID Connect Provider DID Profile v0.1. DIF Working Group Draft
    At no place within these two do= cuments, it is possible to imagine that "the AS will be running on the= user device".
    From section 3 of the DIF Working Group Draft:
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Unlike the = OIDC Authorization Code Flow as per [OIDC.Core], the SIOP will not return a= n access token to the RP".
    An Identity Wallet is not an AS.=C2=A0
    =

    =
    Roles:=C2=A0
    -> g= rant endpoint of the AS: Why is this a post request? This eliminates the ch= ance of having user device hosted AS (no server).
    [FI] what would you propo= se instead?
    Would= also be interested to understand better the deployment model when there is= no server. That's something that was discussed several times but I'= ;m still missing the underlying architecture and use case.
    =C2=A0[FP] See above (SIOP). There will be a lot of identity walle= ts operated on end user device.
    <= div style=3D"margin-top:0px;margin-bottom:0px">See the above comment. Pleas= e, do not confuse an Identity Wallet with an Authentication Server (AS).
    Denis

    -> Resource Owner (RO) : Authorizes the request? Does it autho= rize the request or the access to a resource?
    =
    [FI] yes, we should make the = wording clearer

    Missing Section Interactions:
    --> = This section shall introduce the notion of interaction before we start list= ing interaction types.
    [FI] yes=C2=A0
    =

    Interaction Types:
    -->= I prefer a classification with Redirect, Decoupled and Embedded is. In the= draft, we have one redirect and 2 decouple interactions and nothing else.<= /div>
    = [FI] this should be handled as a specific discussion item. As a reminder, h= ow would you define embedded?

    In practice there's at least these modes:
    - redirect and redi= rect back
    - redir= ect to different browser or device
    - user code
    - CIBA
    [FP] This classification is limited.
    • Redirect: same de= vice, same or different user agents (browser, mobile app, desktop app, ...)=
    • Decoupled: different devices
    • Embedded : RC carries RO auth= orization to AS


    =
    =
    Resource Access Request vs. Resou= rce Request
    --> Both are mixed up. No cla= rification of the context of each section.
    [FI] could you clarify what you&= #39;d expect.=C2=A0 Btw on this topic, there's a more general discussio= n on whether we should make a distinction or not.=C2=A0
    [FP= ]: Here:
    • Resource A= ccess Request: Requesting Access to a resource. Response is an access token= (or any type of grant)
    • Resource Request: Request the resource. Response is the resource (or= a corresponding execution)

    Token Content Negotiation
    --> Not expressed as such. This is central to GNAP and n= ot represented enough=C2=A0 in the document.
    <= div style=3D"margin:0px">[FI] right. This should be a s= pecific discussion item.=C2=A0

    Requesting "User" Information
    we identify two types of users: RQ and RO. It will be bet= ter not to refer to a user in this draft, but either to a RQ or an RO.
    [FI]= yes that would avoid potential misunderstandings. Although in the end, peo= ple will translate RQ into user=C2=A0or end-user most of the time. Cf in de= finition, currently we have=C2=A0Requestin= g Party (RQ, aka "user")


    Interaction Again
    -> For each interaction type, we wi= ll have to describe the protocol flow and the nature and behavior of involv= ed Roles (Parties), Elements, Requests.
    =
    [FI] yes=C2=A0=C2=A0

    [FP] W= ill these and into tickets?

    Best regards.
    /Francis


    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.= org
    https://www.ietf.org/mailman/listinfo/txauth
    -= -=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    --=C2=A0
    TXAuth mailing list<= br>TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth
    --=C2=A0
    TX= Auth mailing list
    TXAuth@ietf.org<= br>https= ://www.ietf.org/mailman/listinfo/txauth

    --=C2=A0
    TXAuth mailing list
    T= XAuth@ietf.org
    https://www.ietf.or= g/mailman/listinfo/txauth

    <= /blockquote>

    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.= org
    https://www.ietf.or= g/mailman/listinfo/txauth

    = --=C2=A0
    TXAuth mailing list=
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    --0000000000002dbe3805bad50344-- From nobody Mon Feb 8 08:44:27 2021 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 80BD83A118E for ; Mon, 8 Feb 2021 08:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 FQX7yWfFVDhw for ; Mon, 8 Feb 2021 08:44:21 -0800 (PST) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 F05463A118C for ; Mon, 8 Feb 2021 08:44:20 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id a16so13355439ilq.5 for ; Mon, 08 Feb 2021 08:44:20 -0800 (PST) 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=txdzOIBQ7SQHtyz3xEn+4ngDWi9DLvGYuVNRbNg08pc=; b=o+EJtTV+IU5lTTQvd+LSmCtY3OOnyEX9LIBmdv4rGUNkk0i/E1r+m5KPw/Tv4LKPH4 qgMpWRFqT+0h2rd+NTFtNgPi0OQqXeCXfNfItAeK6fdFgrAB28I3q71N1yBv0rbgkoUf f+I//J/kKDTl4BJBKBfEXi6uN0RPzNZj0N3/8SIv71ZgOxT6xMDpPzSPSTvJoiTRWNLC ijSKZ+F3g38SegVRMnFkApYsc5/t7vCRNlYCP5zTEvG5qjXlWQCxQSVEPywM6JlMe2mk 2vnxVO+8sb1c/ueyI5hbpFEGpuwbYBhLEzdpjld15ZMFiSm/eBxthDh3Py9mooJDXzeS CSpQ== 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=txdzOIBQ7SQHtyz3xEn+4ngDWi9DLvGYuVNRbNg08pc=; b=RUhSZby8v3+i9XgTuoMVOFFeKBypJX0AIwOOiNGT+q52dHwYiYSTcMPJlvhVQwqWEd u4BHW04A7FXp/1zf1HbE6pA6aqPVbClmVHlk+GW/S89i0t1XoS5zTcoy9f1tCpYBjjfX xHbhEcxI3ZhhtvTmHFM6euU2Uy494qKLhFCZ1q2iUF1LrNGaebSXcRjedRFZ79+MvqA8 czzNs/msy8fAGz44UaYpu3bLF+dSvrdXJ9pTa6PW6ocZGUC+9nUXYJuQhv2SW+81vEc1 FmKpruQ0ewD20G9+DCqKlqDn0rKC2+QrnHdkrfW0PXF/GJgCGWJcBfRDpTEtGjoOw8Dx UtNw== X-Gm-Message-State: AOAM532fkX+nQB3e6QSXDBGR5ISbxXlxrOvK4UiBXRYUqzw0i+nTYHto igkGaGg/0YImpQzwQ38tKoWaK6YNduv6nArEgcL4khQNkB8Tcw== X-Google-Smtp-Source: ABdhPJzftUWmTQDxL5c9OxaygK3NXGrasy9zrBL2sa+G2PrBGcg5dn10m0zw8UyrsxJGvQdufZYw9X+GTuBAP3BBpNo= X-Received: by 2002:a05:6e02:1a03:: with SMTP id s3mr17236160ild.178.1612802660039; Mon, 08 Feb 2021 08:44:20 -0800 (PST) MIME-Version: 1.0 References: <7A612194-5C4B-4658-B7F0-E6058D044255@mit.edu> In-Reply-To: From: Fabien Imbault Date: Mon, 8 Feb 2021 17:44:08 +0100 Message-ID: To: Francis Pouatcha Cc: Tom Jones , Justin Richer , Francis Pouatcha , Adrian Gropper , txauth gnap Content-Type: multipart/alternative; boundary="000000000000a502fe05bad5e14b" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 16:44:26 -0000 --000000000000a502fe05bad5e14b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, virtual interim meeting on 2021-02-10 from 16:00 to 17:00 UTC https://intuit.zoom.us/j/99481776837?from=3Daddon - Review of changes since IETF109 (including edits since -03) - Interaction mode changes (issue #122) - Discussion of next steps Cheers. Fabien On Mon, Feb 8, 2021 at 5:33 PM Francis Pouatcha < Francis.Pouatcha@adorsys.com> wrote: > Hello Fabian, > > what time is the interim Meeting on Wednesday? > > Can you forward the invite? > > Best regards, > /Francis > ------------------------------ > *From:* Fabien Imbault > *Sent:* Monday, February 8, 2021 9:57 AM > *To:* Tom Jones > *Cc:* Justin Richer ; Francis Pouatcha ; > Adrian Gropper ; txauth gnap > *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > > +1 > The interim meeting planned on Wednesday will be a good opportunity to > discuss interactions ! > > Fabien > > On Mon, Feb 8, 2021 at 2:22 PM Tom Jones > wrote: > > Justin +1 > > thx ..Tom (mobile) > > On Mon, Feb 8, 2021, 5:19 AM Justin Richer wrote: > > I agree that the focus of this group does need to be on an HTTP-based AS = =E2=80=94 > this particular use case is the one that we have to solve for, and that= =E2=80=99s > why those details are called out in the charter. We aren=E2=80=99t here t= o try to > build a transport-independent security language, with abstractions and > bindings and things of that sort. But that said, the =E2=80=9Con-device A= S=E2=80=9D use > case is being brought up a lot, and solutions have been hacked together i= n > the OAuth 2 world in several different ways. As such, we as a WG should b= e > paying attention to them, and if there are things we can do in our design > to allow for that kind of deployment then we need to consider them. That > doesn=E2=80=99t mean we have to have that fully specified in the core pro= tocol, but > if there=E2=80=99s a way to design this so that it can be extended in tha= t > direction without the kind of hacks that the OAuth 2 solutions have to re= ly > on, then it=E2=80=99ll be better for everyone. This can=E2=80=99t distrac= t us from solving > the core use cases, or drive us to making the core so complex that it > becomes irrelevant, but we shouldn=E2=80=99t be blind to these other poss= ibilities. > > In my opinion as a contributor, the best opportunities we have for that > kind of extension in the way the protocol=E2=80=99s built right now are i= n the > interaction and continuation pieces of GNAP. Interaction we=E2=80=99ve al= ways known > was going to allow for a move off-browser, and less dependence on > user-in-a-browser is baked into the charter as well. But we need more > experience and more details about :how: that works, and that=E2=80=99s a = lot of > what this current conversation is going to be about. You are completely > right that there are another set of challenges, but in my mind it=E2=80= =99s that > the trust model is simply different. What do I trust more, a device in my > pocket or a web server in someone else=E2=80=99s data center? There isn= =E2=80=99t an easy > or universal answer to that question, as it turns out. > > =E2=80=94 Justin > > On Feb 7, 2021, at 5:51 PM, Francis Pouatcha wrote: > > Hello Fabian, > > I am sorry for the delayed reply, but very busy working on those > decentralized use cases where tokens a produced on the user device. > > > Like we can see in this thread, it is not obvious to have those use cases > considered in GNAP (as the GNAP charter mentions reliance on HTTP based A= S). > > If the role of an AS is to produce an authorization, a user device hosted > AS can be build, but the negotiation process will be different from the o= ne > defined by GNAP. Means interaction protocol will need more than just HTTP= . > > The biggest challenge we are facing on user device produced auth tokens i= s > on how to preserve those crypto keys held on user device from malware, lo= ss > of device... > > For the moment keeping focus of GNAP on (http) server-based production of > token looks like a good decision. > > I will review the draft sometime as soon as possible and provide my > feedback. > > Best regards, > > /Francis > > ------------------------------ > *From:* TXAuth on behalf of Fabien Imbault < > fabien.imbault@gmail.com> > *Sent:* Friday, February 5, 2021 3:41 PM > *To:* Adrian Gropper > *Cc:* Tom Jones ; txauth gnap < > txauth@ietf.org>; Justin Richer > *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > > Hi Adrian, > > We would be glad to get your expertise on that. Not sure DIDComm is > essential yet, so far I see it personally as something to look into, > especially for use cases when we want to reach out to a RO. I agree with > the potential issues. > > I have a few ideas on how to implement privacy, but it's quite involved i= n > terms of crypto (again using Ristretto groups :-)). > > Of course there will be a question of priority in the features we plan to > implement. I guess we should aim for a first publication without the part= s > which are blurry, and take the time to prototype the rest. > > Cheers > Fabien > > Le ven. 5 f=C3=A9vr. 2021 =C3=A0 21:19, Adrian Gropper a > =C3=A9crit : > > There are privacy implications as well as the cost of processing spam. A > service endpoint associated with a DID can be presumed to be a public > broadcast. Any party can attempt to send a message or an authorization > request to that service endpoint. The operator of that service, typically > the DID controller, will bear the cost and risk of processing the message= . > They may request a bond be posted by the party responding to the > "broadcast" in order to mitigate spam and phishing. They may also require > that the party seeking to communicate offer credentials, which poses a > privacy risk to that party in the form of phishing "broadcasts" via DIDs > and lures that lead to DIDs. > > In my role as invited expert on privacy to some W3C WGs and, to some > extent, DIF WGs, I have not managed to understand the privacy engineering > and implications in DIDcomm. I will try harder if DIDcomm has an essentia= l > role with GNAP and I can understand it in the self-sovereign or fiduciary > authorization server context. Does it? > > Adrian > > On Fri, Feb 5, 2021 at 1:08 PM Fabien Imbault > wrote: > > Probably (and to be honest even for industrial users I find it complex), > but alternatives are not ready for prime time either. > Maybe some day DIDComm could be useful as a basic block, what we suggest > is to first use that as a potential interaction (and there's already a lo= t > of questions that arise just from that). > > Fabien > > On Fri, Feb 5, 2021 at 6:55 PM Tom Jones > wrote: > > No, you didn't misunderstand me. It's just that the ux for that is not > acceptable to retail users. As long as gnap sticks to industrial users yo= u > should do fine. > > thx ..Tom (mobile) > > On Fri, Feb 5, 2021, 7:56 AM Fabien Imbault > wrote: > > Targeting existing browsers and types of applications (web, pwa, mobile, > etc.) seems like a reasonable option for an industrial standard. Improvin= g > security, privacy, ease of use and interoperability (including > decentralized identity as well) should be good enough objectives. > Plus from our previous discussions, I was under the impression you were > fine with the approach of deploying the AS on the phone as a loopback, fo= r > mobile apps. Did I miss something? > > Cheers, > Fabien > > Le ven. 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones a > =C3=A9crit : > > If you mean can GNAP work on old fashioned apps running with existing > browsers and existing identity providers, then yes, i guess you are ok. > > If you want to work on apps where the user is in control of authn and > authz, then no, GNAP cannot work. It is not alone in that OIDC wont work > there either. > > Be the change you want to see in the world ..tom > > > On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault > wrote: > > Hi Tom, > > Thanks, your responses made it clearer for me what you expect from an AS > deployed on a mobile. > > I think we're on the right path to meet the rest of your concerns. There > are already a few items on these: > - privacy preserving techniques have been discussed and are likely to be > included (I think). It's been recognized as a core concern > - not exactly sure the meaning you give to discovery here (it's already > been used in the WG but with a different meaning I believe). The request = or > the continuation api provide entry points to pay attention to. > > Is that enough for your use case ? Do you need something else ? (like SSE= ?) > > Cheers > Fabien > > Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom Jones a > =C3=A9crit : > > discovery is the prime problem. What causes the wallet/AS to wake up and > pay attention. How does the RP know what to ask for without violating use= r > privacy rights? > > CHAPI would be ok i guess, but that requires cred man to be fixed. Not > sure if it fixes discovery or privacy even then. > > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 12:45 PM Justin Richer wrote: > > Tom, what additional functionality do you see that a browser would need t= o > support in order for GNAP to be adopted? For the elements of the core > protocol today, nothing is needed to change within the browsers =E2=80=94 > everything is built on existing functions. GNAP uses browsers as a tool, > and I would argue depends on them even less so than OAuth 2 does. > Extensions could use browser functionality, like using CHAPI to pass > interaction elements, but the core protocol functions on vanilla browsers > today. > > =E2=80=94 Justin > > On Feb 4, 2021, at 3:20 PM, Tom Jones > wrote: > > i assumed that the wallet (aka AS) needed to be a native app, not a PWA > (which can come from a traditional web server). > There are folks, lke Kim C, who are working on a PWA, but i agree the > blocks there seem to be large. > THe blocks on a native app are simple, easy to describe, and easy to ask > the browser guys to fix. Not sure if they care tho. > I have trouble seeing a path to GNAP adoption for retail customers w/o > some browser support. > That's why i am mostly silent here. > > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault > wrote: > > Fair enough. But loopback limits a lot what you can do... Just for debug > it's a pain. > But as soon as you try more, it's a bit crazy. Fun to test ipv6 (luckily > supported by my ISP) and ddns. But it feels really hacky. > Also deployment is a pain, compared to a traditional webserver. > > Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones a > =C3=A9crit : > > doesn't work very well on windows uwp. works fine on smartphones > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 11:18 AM Justin Richer wrote: > > OK, thanks =E2=80=94 in that case, there are no changes at all to GNAP, w= hich is > already HTTP driven. The harder parts tend to be where you can=E2=80=99t = (or don=E2=80=99t > want to) use something like that. > > =E2=80=94 Justin > > On Feb 4, 2021, at 2:16 PM, Tom Jones > wrote: > > yes, loopback > > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 11:01 AM Justin Richer wrote: > > Tom, can you expand on how exactly the back-channel communication works > between on-device components? Do you use HTTP locally? > > Thanks, > =E2=80=94 Justin > > On Feb 4, 2021, at 1:03 PM, Tom Jones > wrote: > > Justin's analysis of use of the front channel is misleading. > It could equally be argued that what i have done is installed an AS on th= e > phone and the communications with it & the PR is back channel. > Basically the point is that the old OIDC paradigms are no longer valid. > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault > wrote: > > Yes, issue (#168) message based interaction / DIDComm is a tentative > alternative mecanism for the interaction part. Not sure how that would wo= rk > in details though, prototyping will probably help here. > Token delivery through continuation seems fine to me. The client will > probably have to wait for the next polling before it receives a token > issued as the result of an asynchronous interaction, but that's not a big > issue. > > But the AS on the phone seems like a harder nut to crack, at least at > first sight. I think that would be awesome, but it gives me headaches, so= I > think I'll work on easier stuff right now ;-) > > Fabien > > On Thu, Feb 4, 2021 at 4:30 PM Justin Richer wrote: > > One of the biggest drawbacks of the current app-centric approaches in OID= C > (self-issued OP, or SIOP) is that they depend on using the front channel > and browser redirects to pass everything, which is something that GNAP is > deliberately getting away from by starting in the back channel. > > That said, once a request is kicked off in GNAP, the interaction and > fulfillment can happen through any number of means. Part of the work that= =E2=80=99s > being done with the =E2=80=9Cinteraction=E2=80=9D section is going to hel= p facilitate this, > and I think that there are some other potential branches here. > > Token delivery is where things get extra weird though =E2=80=94 we are ex= plicitly > not delivering tokens in the front channel in the core of GNAP, we=E2=80= =99re using > the response from the continuation API. One idea (that isn=E2=80=99t part= icularly > well thought out and hasn=E2=80=99t been implemented at all) is to have a= n > extension declare an alternative response from the =E2=80=9Ccontinue=E2= =80=9D section > that=E2=80=99s defined today, which points to the GNPA continuation API. = If an > extension defines some alternative way to deliver tokens, that could live > alongside a continuation API and the client could indicate support for it > in its initial request. > > In any event, alternative interaction and delivery methods are important, > and even if we aren=E2=80=99t going to support every last one of them dir= ectly, the > protocol design should at least be aware of them. > > =E2=80=94 Justin > > On Feb 4, 2021, at 8:35 AM, Fabien Imbault > wrote: > > Hi Tom, > > Sure, any experience on that would be greatly appreciated, we're calling > for help here (the point being that I suspect what they're doing is not > trivial). > > Fabien > > On Thu, Feb 4, 2021 at 2:21 PM Tom Jones > wrote: > > I've had such an app working for over a year. There are issues which are > being addressed by the browser Interaction team of oidc. > > thx ..Tom (mobile) > > On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault > wrote: > > Hi Francis, > > I've tried a few things with regards to using the AS on a phone, but it's > really quite complex. > > Making that run on a phone comes with quite a bit of trouble. The most > difficult part if that we'd need to use a secure element, but just > installing and hosting a http server securely is not a standard setup at > all. I suggest interested people step in to work on this, as we already > have a lot of work for the (more usual) server case and already handle a > privacy preserving scheme. > > Please let us know what you think. > > Cheers, > Fabien > > On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault > wrote: > > Hi Francis, > > I've thought a bit more to what you said. I think I'll give it a try as a > separate experiment (in code, not in theory). Not that I would expect it = to > be included in GNAP, but I kind of like the idea :-) > > The direct impact for GNAP would be to think about multiple ASs. > > Will let you know. > > Fabien > > > Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha a = =C3=A9crit : > > It would be nice if the protocol was designed at many layers of > abstraction. > > > - The first layer shall design abstract protocol flows, without > specification of the mode and mechanism of interaction. > - The second layer can instantiate the first layer for dedicated > interaction. Here we can talk http, we can define interactions that pr= esume > server based token generation, we can define interaction that run on u= ser > device based token generation. > > This is also the fundament of the structure I proposed for the spec ( > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). > > /Francis > > ------------------------------ > *From:* Fabien Imbault > *Sent:* Wednesday, November 18, 2020 6:35 AM > *To:* Francis Pouatcha > *Cc:* txauth@ietf.org ; Dick Hardt ; > Tom Jones ; Denis ; > Justin Richer > *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > > Would make sense, but not so easy as we rely heavily on HTTP. Hence the > discussion about deep links and so on. > > An alternative might be provided by wasm/wasi (running a local sandbox on > your phone, for your own AS), but it's really early stage. This also pose= s > another question that Denis has put forward, i.e. how do we handle the > multiple AS scenario (likely to occur then). > > Fabien > > On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha wrote: > > We are drifting away from the original problem space. > > - My original mention was about the "POST" request, that subsumes that > the "AS" is a "Server". Designing a new protocol, we cannot afford thi= s > limitation. > - I just mentioned SIOP to show a known and closed example? Let us not > focus on the device local discovery scheme (like openid:) for now. > - As capability of holding private keys on user device evolves, > server-based issuing of token will be fading out giving way to device = local > generation of token. > > While designing GNAP, let us assume the AS-Role can be exercised on a use= r > device and design the protocol to honor that. > > Best regards, > /Francis > ------------------------------ > *From:* TXAuth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Sent:* Tuesday, November 17, 2020 1:28 PM > *To:* Tom Jones > *Cc:* Fabien Imbault ; Denis ; > GNAP Mailing List ; Justin Richer > *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > > Got it. > > So web apps invoke a openid: deep link and hope there is an app to handle > the openid: scheme? ... and that it is the user's wallet rather than some > malware that has registered openid: on the mobile device? > > A native app can attempt to open a deep link associated with an app, and > will fail if the app is not there. If the app is there, it will be opened= , > so this can't be used to silently test if an app is present, but it does > allow a native app to provide an alternative experience if an app is not > present. I don't think this works with custom schemes ... and I don't kno= w > how it could work from a web app on the phone with the current Safari API= s. > > Apple warns against using custom schemes [1] ... but perhaps they can be > convinced to make openid: a managed scheme similar to mailto:, tel:, > sms:, facetime: ? > > [1] > https://developer.apple.com/documentation/xcode/allowing_apps_and_website= s_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app > > > =E1=90=A7 > > On Tue, Nov 17, 2020 at 10:06 AM Tom Jones > wrote: > > You are - that is not standard which is opeind:// > This is the one step that still needs to be optimized for SIOP to have > good UX. > Peace ..tom > > > On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt wrote: > > Hi Tom > > I watched your video (I watched at 2X speed) > > Looks like the employment website app that is using localhost:8765 to > communicate with the wallet. Am I correct? > > /Dick > =E1=90=A7 > > On Tue, Nov 17, 2020 at 9:46 AM Tom Jones > wrote: > > Well, here's a demo. Note that in this case the AS is not online all of > the time, so it is really implicit flow and the OIDC id-token comes from > the siop device directly. > (whether this is front-channel or back channel is no longer an interestin= g > question.) > Now if an always-on AS is required, that is possible, but probably beyond > the scope of this effort and would require something like an > agent-in-the-sky (with diamonds). > here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 > > Peace ..tom > > > On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: > > Ultimately, in most situations like these in the real world, the hurdle > isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP > (client) needs to have some incentive to trust the assertions and identit= y > information that=E2=80=99s coming from the AS. The same is true for an RS= trusting > tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to do= that (which SSI > answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, > because it=E2=80=99s a hard question). > > Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on device=E2=80=9D > element. We=E2=80=99ve got the start of it more than OAuth2/OIDC have by = allowing > the bootstrap of the process from a starting call: the interaction and > continuation URIs handed back by the AS don=E2=80=99t need to be the same= URIs that > the client starts with, so just like SIOP the process can start in HTTP a= nd > potentially move to other communication channels. A major difference is > that we aren=E2=80=99t dependent on the assumption that the user will alw= ays be in > a browser at some stage, and so the whole raft of front-channel messages > that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got an = opportunity to > more explicitly open up alternative communication channels here, and that= =E2=80=99s > something I=E2=80=99d like to see engineered, even if it=E2=80=99s an ext= ension. I=E2=80=99d love > to see a concrete proposal as to how that would work over specific > protocols, starting with what we=E2=80=99ve got today. > > =E2=80=94 Justin > > On Nov 17, 2020, at 12:03 PM, Fabien Imbault > wrote: > > Hi Denis, hi Francis, > > At some point integration with SSI (on the authentication side) will > probably occur, including amongst other possibilities SIOP (since they wo= rk > with OpenID a part of the work will probably be made easier). > > That being said, Denis is right. It's not an AS. Technically it's entirel= y > possible to rely on a decentralized wallet (for instance on your phone) a= nd > a centralized AS. I know of a few studies on how to decentralize the AS > itself (for instance > https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). > Maybe it exists, but I'm still looking for real scenarios (or even > architectures) where an AS is deployed directly on a phone, and under the > sole authority of the RO, while being compatible with the rest of the > world. > > Cheers, > Fabien > > On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: > > Hello Francis, > > See two comments in line. > > > B) Current Document > > Roles description shall not hold any assumption on the physical structure > of the party fulfilling the roles. > [FI] not sure what you mean > > [FP] for example, we assume the AS is a server! In most SSI based use > cases, the AS will be running on the user device. See SIOP ( > https://identity.foundation/did-siop/). > > I browsed through the two drafts, i.e. : > > - Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, > and representations W3C Working Draft 08 November 2020 > - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working > Group Draft > > At no place within these two documents, it is possible to imagine that > "the AS will be running on the user device". > From section 3 of the DIF Working Group Draft: > "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the > SIOP will not return an access token to the RP". > An Identity Wallet is not an AS. > > > Roles: > -> grant endpoint of the AS: Why is this a post request? This eliminates > the chance of having user device hosted AS (no server). > [FI] what would you propose instead? > Would also be interested to understand better the deployment model when > there is no server. That's something that was discussed several times but > I'm still missing the underlying architecture and use case. > > [FP] See above (SIOP). There will be a lot of identity wallets operated > on end user device. > > See the above comment. Please, do not confuse an Identity Wallet with an > Authentication Server (AS). > Denis > > > -> Resource Owner (RO) : Authorizes the request? Does it authorize the > request or the access to a resource? > [FI] yes, we should make the wording clearer > > Missing Section Interactions: > --> This section shall introduce the notion of interaction before we star= t > listing interaction types. > [FI] yes > > Interaction Types: > --> I prefer a classification with Redirect, Decoupled and Embedded is. I= n > the draft, we have one redirect and 2 decouple interactions and nothing > else. > [FI] this should be handled as a specific discussion item. As a reminder, > how would you define embedded? > > In practice there's at least these modes: > - redirect and redirect back > - redirect to different browser or device > - user code > - CIBA > > [FP] This classification is limited. > > - Redirect: same device, same or different user agents (browser, > mobile app, desktop app, ...) > - Decoupled: different devices > - Embedded : RC carries RO authorization to AS > > > > Resource Access Request vs. Resource Request > --> Both are mixed up. No clarification of the context of each section. > [FI] could you clarify what you'd expect. Btw on this topic, there's a > more general discussion on whether we should make a distinction or not. > > [FP]: Here: > > - Resource Access Request: Requesting Access to a resource. Response > is an access token (or any type of grant) > - Resource Request: Request the resource. Response is the resource (or > a corresponding execution) > > > Token Content Negotiation > --> Not expressed as such. This is central to GNAP and not represented > enough in the document. > [FI] right. This should be a specific discussion item. > > Requesting "User" Information > we identify two types of users: RQ and RO. It will be better not to refer > to a user in this draft, but either to a RQ or an RO. > [FI] yes that would avoid potential misunderstandings. Although in the > end, people will translate RQ into user or end-user most of the time. Cf = in > definition, currently we have Requesting Party (RQ, aka "user") > > > Interaction Again > -> For each interaction type, we will have to describe the protocol flow > and the nature and behavior of involved Roles (Parties), Elements, Reques= ts. > [FI] yes > > > [FP] Will these and into tickets? > > Best regards. > /Francis > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000a502fe05bad5e14b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi,

    virtual=C2=A0interim=C2=A0meeting on 2021-02-10 from 16:00 to 17:00 UTC

    - Review of changes since IETF109= (including edits since -03)
    - Interaction mode changes (issue #122)
    = - Discussion of next steps

    Cheers.
    F= abien

    On Mon, Feb 8, 2021 at 5:33 PM Francis Pouatcha <Francis.Pouatcha@adorsys.com> wr= ote:
    Hello Fabian,

    what time is the interim Meeting on Wednesday?

    Can you forward the invite?

    Best regards,
    /Francis
    Fro= m: Fabien Imbault <fabien.imbault@gmail.com>
    Sent: Monday, February 8, 2021 9:57 AM
    To: Tom Jones <thomasclinganjones@gmail.com>
    Cc: Justin Richer <jricher@mit.edu>; Francis Pouatcha <fpo@adorsys.de>; Adrian Gropper <agropper@healthur= l.com>; txauth gnap <txauth@ietf.org>
    Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
    =C2=A0
    +1=C2=A0
    The interim meeting planned on Wednesday will be a good opportunity to= discuss interactions !

    Fabien

    On Mon, Feb 8, 2021 at 2:22 PM Tom Jones <thomasclinganjones@gma= il.com> wrote:
    Justin +1

    thx ..Tom (mobile)

    On Mon, Feb 8, 2021, 5:19 AM Justin Richer <jricher@mit.edu> wrote:
    I agree that the focus of this group does need to be on an HTTP-based = AS =E2=80=94 this particular use case is the one that we have to solve for,= and that=E2=80=99s why those details are called out in the charter. We are= n=E2=80=99t here to try to build a transport-independent security language, with abstractions and bindings and things of that sort.= But that said, the =E2=80=9Con-device AS=E2=80=9D use case is being brough= t up a lot, and solutions have been hacked together in the OAuth 2 world in= several different ways. As such, we as a WG should be paying attention to them, and if there are things we can do in our desi= gn to allow for that kind of deployment then we need to consider them. That= doesn=E2=80=99t mean we have to have that fully specified in the core prot= ocol, but if there=E2=80=99s a way to design this so that it can be extended in that direction without the kind of hacks tha= t the OAuth 2 solutions have to rely on, then it=E2=80=99ll be better for e= veryone. This can=E2=80=99t distract us from solving the core use cases, or= drive us to making the core so complex that it becomes irrelevant, but we shouldn=E2=80=99t be blind to these other possi= bilities.

    In my opinion as a contributor, the best opportunities we have for tha= t kind of extension in the way the protocol=E2=80=99s built right now are i= n the interaction and continuation pieces of GNAP. Interaction we=E2=80=99v= e always known was going to allow for a move off-browser, and less dependence on user-in-a-browser is baked into the charter as well= . But we need more experience and more details about :how: that works, and = that=E2=80=99s a lot of what this current conversation is going to be about= . You are completely right that there are another set of challenges, but in my mind it=E2=80=99s that the trust mode= l is simply different. What do I trust more, a device in my pocket or a web= server in someone else=E2=80=99s data center? There isn=E2=80=99t an easy = or universal answer to that question, as it turns out.

    =C2=A0=E2=80=94 Justin

    On Feb 7, 2021, at 5:51 PM, Francis Pouatcha <fpo@adorsys.de> wr= ote:

    Hello Fabian,

    I am sorry for the delayed reply, but very busy working on those decentrali= zed use cases where tokens a produced on the user device.


    Like we can see in this thread, it is not obvious to have those use cases c= onsidered in GNAP (as the GNAP charter mentions reliance on HTTP based AS).=

    If the role of an AS is to produce an authorization, a user device hosted A= S can be build, but the negotiation process will be different from the one = defined by GNAP. Means interaction protocol will need more than just HTTP.<= /div>

    The biggest challenge we are facing on user device produced auth tokens is = on how to preserve those crypto keys held on user device from malware, loss= of device...

    For the moment keeping focus of GNAP on (http) server-based production of t= oken looks like a good decision.

    I will review the draft sometime as soon as possible and provide my feedbac= k.

    Best regards,

    /Francis

    From:=C2=A0TXAuth <txauth-bounces@ietf.org> on behalf= of Fabien Imbault <fabien.imbault@gmail.com>
    Sent:=C2=A0Friday, February 5, 2021 3:41 PM
    To:=C2=A0Adrian Gropper <agropper@healthurl.com<= /a>>
    Cc:=C2=A0Tom Jones <    thomasclinganjones@gma= il.com>; txauth gnap <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
    Subject:=C2=A0Re: [GNAP] Review of draft-ietf-gnap-core= -protocol-00
    =C2=A0
    Hi Adrian,

    We would be glad to get your expertise on that. Not sure = DIDComm is essential yet, so far I see it personally as something to look i= nto, especially for use cases when we want to reach out to a RO. I agree wi= th the potential issues.=C2=A0

    I have a few ideas on how to implement privacy, but it= 9;s quite involved in terms of crypto (again using Ristretto groups :-)).

    Of course there will be a question of priority in the fea= tures we plan to implement. I guess we should aim for a first publication w= ithout the parts which are blurry, and take the time to prototype the rest.= =C2=A0

    Cheers
    Fabien=C2=A0

    Le ven. 5 f=C3=A9vr. 2021 =C3=A0 21:19, Adrian Gropper <= ;agropper@healthurl.com> a =C3=A9crit=C2=A0:
    There are privacy implications as well as the cost of proc= essing spam. A service endpoint associated with a DID can be presumed to be= a public broadcast. Any party can attempt to send a message or an authoriz= ation request to that service endpoint. The operator of that service, typically the DID controller, will bear the = cost and risk of processing the message. They may request a bond be posted = by the party responding to the "broadcast" in order to mitigate s= pam and phishing. They may also require that the party seeking to communicate offer credentials, which poses a privacy = risk to that party in the form of phishing "broadcasts" via DIDs = and lures that lead to DIDs.=C2=A0

    In my role as invited expert on privacy to some W3C WGs and, to some e= xtent, DIF WGs, I have not managed to understand the privacy engineering an= d implications in DIDcomm. I will try harder if DIDcomm has an essential ro= le with GNAP and I can understand it in the self-sovereign or fiduciary authorization server context. Does i= t?

    Adrian

    On Fri, Feb 5, 2021 at 1:08 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Probably (and to be honest even for industrial users I fin= d it complex), but alternatives are not ready for prime time either.=C2=A0
    Maybe some day=C2=A0DIDComm could be useful as a basic block, what we = suggest is to first use that as a potential interaction (and there's al= ready a lot of questions that arise just from that).=C2=A0

    Fabien

    On Fri, Feb 5, 2021 at 6:55 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
    No, you didn't misunderstand me. It's just that t= he ux for that is not acceptable to retail users. As long as gnap sticks to= industrial users you should do fine.

    thx ..Tom (mobile)

    On Fri, Feb 5, 2021, 7:56 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Targeting existing browsers and types of applications (web, pwa, mobil= e, etc.) seems like a reasonable option for an industrial standard. Improvi= ng security, privacy, ease of use and interoperability (including decentral= ized identity as well) should be good enough objectives.=C2=A0
    Plus from our previous discussions, I was under the impression you wer= e fine with the approach of deploying the AS on the phone as a loopback, fo= r mobile apps. Did I miss something?

    Cheers,
    Fabien

    Le ven. 5 f=C3=A9vr. 2021 =C3=A0 16:33, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9cr= it=C2=A0:
    If you mean can GNAP work on old fashioned apps running with existing = browsers and existing identity providers, then yes, i guess you are ok.

    If you want to work on apps where the user is in control of authn and = authz, then no, GNAP cannot work. It is not alone in that OIDC wont work th= ere either.

    Be the change you want to see in the world ..tom


    On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Tom,=C2=A0

    Thanks, your responses made it clearer for me what you ex= pect from an AS deployed on a mobile.=C2=A0

    I think we're on the right path to meet the rest of y= our concerns. There are already a few items on these:
    - privacy preserving techniques have been discussed and a= re likely to be included (I think). It's been recognized as a core conc= ern=C2=A0
    - not exactly sure the meaning you give to discovery here= (it's already been used in the WG but with a different meaning I belie= ve). The request or the continuation api provide entry points to pay attent= ion to.=C2=A0

    Is that enough for your use case ? Do you need something else ? (like = SSE?)

    Cheers
    Fabien=C2=A0

    Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 22:10, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit=C2=A0:
    discovery is the prime problem.=C2=A0 What causes the wall= et/AS to wake up and pay attention. How does the RP know what to ask for wi= thout violating user privacy rights?

    CHAPI would be ok i guess, but that requires cred man to be fixed. Not= sure if it fixes discovery or privacy even then.

    Be the change you want to see in the world ..tom


    On Thu, Feb 4, 2021 at 12:45 PM Justin Richer <jricher@mit.edu> wrote:
    Tom, what additional functionality do you see that a browser would nee= d to support in order for GNAP to be adopted? For the elements of the core = protocol today, nothing is needed to change within the browsers =E2=80=94 e= verything is built on existing functions. GNAP uses browsers as a tool, and I would argue depends on them even less = so than OAuth 2 does. Extensions could use browser functionality, like usin= g CHAPI to pass interaction elements, but the core protocol functions on va= nilla browsers today.

    =C2=A0=E2=80=94 Justin

    On Feb 4, 2021, at 3:20 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

    i assumed that the wallet (aka AS) needed to be a native a= pp, not a PWA (which can come from a traditional web server).
    There are folks, lke Kim C, who are working on a PWA, but i agree the = blocks there seem to be large.
    THe blocks on a native app are simple, easy to describe, and easy to a= sk the browser guys to fix. Not sure if they care tho.
    I have trouble seeing a path to GNAP adoption for retail customers w/o= some browser support.
    That's why i am mostly=C2=A0silent here.

    Be the change you want to see in the world ..tom


    On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Fair enough. But loopback limits a lot what you can do...= Just for debug it's a pain.=C2=A0
    But as soon as you try more, it's a bit crazy. Fun to= test ipv6 (luckily supported by my ISP) and ddns. But it feels really hack= y.=C2=A0
    Also deployment is a pain, compared to a traditional webs= erver.=C2=A0

    Le jeu. 4 f=C3=A9vr. 2021 =C3=A0 20:20, Tom Jones <thomasclinganjones@gmail.com> a =C3=A9crit=C2=A0:
    doesn't work very well on windows uwp. works fine on s= martphones
    Be the change you want to see in the world ..tom


    On Thu, Feb 4, 2021 at 11:18 AM Justin Richer <jricher@mit.edu> wrote:
    OK, thanks =E2=80=94 in that case, there are no changes at all to GNAP= , which is already HTTP driven. The harder parts tend to be where you can= =E2=80=99t (or don=E2=80=99t want to) use something like that.

    =C2=A0=E2=80=94 Justin

    On Feb 4, 2021, at 2:16 PM, Tom Jones <tho= masclinganjones@gmail.com> wrote:

    yes, loopback

    Be the change you want to see in the world ..tom


    On Thu, Feb 4, 2021 at 11:01 AM Justin Richer <jricher@mit.edu> wrote:
    Tom, can you expand on how exactly the back-channel =C2=A0communicatio= n works between on-device components? Do you use HTTP locally?

    Thanks,
    =C2=A0=E2=80=94 Justin

    On Feb 4, 2021, at 1:03 PM, Tom Jones <tho= masclinganjones@gmail.com> wrote:

    Justin's analysis of use of the front channel is misle= ading.
    It could equally be argued that what i have done is installed an AS on= the phone and the communications with it & the PR is back channel.
    Basically the point is that the old OIDC paradigms are no longer valid= .
    Be the change you want to see in the world ..tom


    On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Yes, issue (#168)=C2=A0message based interaction / DIDComm= is a tentative alternative mecanism for the interaction part. Not sure how= that would work in details=C2=A0though, prototyping will probably help her= e.
    Token delivery=C2=A0through continuation seems fine to me. The client = will probably have to wait for the next polling before it receives a token = issued as the result of an asynchronous interaction, but that's not a b= ig issue.

    But the AS on the phone seems like a harder nut to crack, at least at = first sight. I think that would be awesome, but it gives me headaches, so I= think I'll work on easier stuff right now ;-)

    Fabien=C2=A0=C2=A0

    On Thu, Feb 4, 2021 at 4:30 PM Justin Richer <jricher@mit.edu> wrote:
    One of the biggest drawbacks of the current app-centric approaches in = OIDC (self-issued OP, or SIOP) is that they depend on using the front chann= el and browser redirects to pass everything, which is something that GNAP i= s deliberately getting away from by starting in the back channel.

    That said, once a request is kicked off in GNAP, the interaction and f= ulfillment can happen through any number of means. Part of the work that=E2= =80=99s being done with the =E2=80=9Cinteraction=E2=80=9D section is going = to help facilitate this, and I think that there are some other potential branches here.

    Token delivery is where things get extra weird though =E2=80=94 we are= explicitly not delivering tokens in the front channel in the core of GNAP,= we=E2=80=99re using the response from the continuation API. One idea (that= isn=E2=80=99t particularly well thought out and hasn=E2=80=99t been implemented at all) is to have an extension declare an alternative re= sponse from the =E2=80=9Ccontinue=E2=80=9D section that=E2=80=99s defined t= oday, which points to the GNPA continuation API. If an extension defines so= me alternative way to deliver tokens, that could live alongside a continuation API and the client could indicate support for it in its ini= tial request.

    In any event, alternative interaction and delivery methods are importa= nt, and even if we aren=E2=80=99t going to support every last one of them d= irectly, the protocol design should at least be aware of them.

    =C2=A0=E2=80=94 Justin

    On Feb 4, 2021, at 8:35 AM, Fabien Imbault <fa= bien.imbault@gmail.com> wrote:

    Hi Tom,=C2=A0

    Sure, any experience on that would be greatly appreciated, we're c= alling for help here (the point being that I suspect what they're doing= is not trivial).

    Fabien

    On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
    I've had such an app working for over a year. There a= re issues which are being addressed by the browser Interaction team of oidc= .

    thx ..Tom (mobile)

    On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Francis,=C2=A0

    I've tried a few things with regards to using the AS on a phone, b= ut it's really quite=C2=A0complex.=C2=A0

    Making that run on a phone comes with quite a bit of trouble. The most= difficult part if that we'd need to use a secure element, but just ins= talling and hosting a http server securely is not a standard setup at all. = I suggest interested people step in to work on this, as we already have a lot of work for the (more usual) ser= ver case and already handle a privacy preserving scheme.=C2=A0

    Please let us know what you think.

    Cheers,
    Fabien=C2=A0

    On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Francis,

    I've thought a bit more to what you said. I think I&#= 39;ll give it a try as a separate experiment (in code, not in theory). Not = that I would expect it to be included in GNAP, but I kind of like the idea = :-)

    The direct impact for GNAP would be to think about multip= le ASs.=C2=A0

    Will let you know.=C2=A0

    Fabien=C2=A0


    Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha <fpo@adorsys.de> a =C3=A9crit=C2=A0:
    It would be nice if the protocol was designed at many layers of abstracti= on.

    • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
    • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
    This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"gmail-m_-6690007058569907425x_gmail-m_8538420302849230796m_853286659562= 2248642x_m_-9198896947569259166gmail-m_2454565993824225076gmail-m_481546071= 7883467013m_4588137701409402545m_3740723253088693496m_-99671316316621892gma= il-m_4891442230495737020m_-8218552788289986907m_-8518815978092546954m_35504= 19800836567560m_-8251187544229342067m_6649396458130137896m_3308803089207789= 488m_-435436554859614529m_2888166142485750597gmail-m_7901394266816005280gma= il-m_-6718184999452512077m_-3004232231493229381m_-8862550958674531306m_4552= 653984562635461m_387929924441527190m_6662104191003806385gmail-m_-5428390703= 41023388gmail-m_-6176056956474019294gmail-m_-3037161202240578685gmail-m_-75= 20389457378808664gmail-m_-3342024782330569254m_8014700032835912204gmail-m_1= 42651873244800559m_8348797445460806175LPlnk338391" rel=3D"noreferrer norefe= rrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer nore= ferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer no= referrer noreferrer noreferrer" target=3D"_blank">https://github.com/ietf-w= g-gnap/gnap-core-protocol/issues/30).

    /Francis

    From:=C2=A0Fabien Imbault <fabien.imbault@gmail.com>
    Sent:=C2=A0Wednesday, November 18, 2020 6:35 AM
    To:=C2=A0Francis Pouatcha <fpo@adorsys.de>
    Cc:=C2=A0txauth@ietf.= org=C2=A0<txauth@ietf= .org>; Dick Hardt <dick.hardt@gmail.com= >; Tom Jones <thomasclingan= jones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>= ;
    Subject:=C2=A0Re: [GNAP] Review of draft-ietf-gnap-core= -protocol-00
    =C2=A0
    Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

    An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

    Fabien=C2=A0

    On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@adorsys.de> wrote:
    We are drifting away from the original problem space.
    • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
    • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
    • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
    While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

    Best regards,
    /Francis
    From:=C2=A0TXAuth <txau= th-bounces@ietf.org> on behalf of Dick Hardt <dick.ha= rdt@gmail.com>
    Sent:=C2=A0Tuesday, November 17, 2020 1:28 PM
    To:=C2=A0Tom Jones <thomasclinganjones@gmail.com>
    Cc:=C2=A0Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@free.fr>; GNAP Mailing List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>= ;
    Subject:=C2=A0Re: [GNAP] Review of draft-ietf-gnap-core= -protocol-00
    =C2=A0
    Got it.=C2=A0

    So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

    A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

    Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



    3D""=E1=90=A7

    On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
    You are - that is not standard which is opeind://
    This is the one step that still needs to be optimized for SIOP to have= good UX.
    Peace ..tom


    On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
    Hi Tom

    I watched your video (I watched at 2X speed)

    Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

    /Dick=C2=A0
    3D""=E1=90=A7

    On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
    Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
    (whether this is front-channel or back channel is no longer an interes= ting question.)
    Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
    here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.be/Tq4hw7X5SW0=
    Peace ..tom


    On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
    Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

    Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

    =C2=A0=E2=80=94 Justin

    On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi Denis, hi Francis,=C2=A0

    At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

    That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-ha= rdjono-oauth-decentralized-02).
    Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

    Cheers,
    Fabien

    On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
    Hello=C2=A0 Francis,

    See two comments in line.


    B) Current Document

    Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
    [FI] not sure what you mean
    = =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).
    I browsed through the two d= rafts, i.e. :
    • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
    • Self-Issued Op= enID Connect Provider DID Profile v0.1. DIF Working Group Draft
    At no place within these tw= o documents, it is possible to imagine that "the AS will be running on= the user device".
    From section 3 of the DIF W= orking Group Draft:
    =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the S= IOP will not return an access token to the RP".
    An Identity Wallet is not a= n AS.=C2=A0
    =
    =
    Roles:=C2=A0
    -> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
    [FI] what would you propose i= nstead?
    Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
    = =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.
    See the above comment. Plea= se, do not confuse an Identity Wallet with an Authentication Server (AS).
    Denis
    =
    -> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
    [FI] yes, we should make the = wording clearer

    Missing Section Interactions:
    --> This section shall introduce the notion of= interaction before we start listing interaction types.
    [FI] yes=C2=A0

    Interaction Types:
    --> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
    [FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

    In practice there's at le= ast these modes:
    - redirect and redirect back<= /font>
    - redirect to different brows= er or device
    - user code
    - CIBA
    [FP] This classification is limited.
    • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
    • Decoupled: different devices
    • Embedded= : RC carries RO authorization to AS
    =

    Resource Access Request vs. Resource Request
    --> Both are mixed up. No clarification of the= context of each section.
    [FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
    = [FP]: Her= e:
    • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
    • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

    Token Content Negotiation
    --> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
    [FI] right. This should be a = specific discussion item.=C2=A0

    Requesting "User" Information
    we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
    [FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


    Interaction Again
    -> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
    [FI] yes=C2=A0=C2=A0

    = [FP] Will these and into tickets?
    =
    = Best regards.
    = /Francis



    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://= www.ietf.org/mailman/listinfo/txauth
    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.or= g/mailman/listinfo/txauth

    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://= www.ietf.org/mailman/listinfo/txauth
    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://= www.ietf.org/mailman/listinfo/txauth

    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txa= uth


    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/l= istinfo/txauth

    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth

    --000000000000a502fe05bad5e14b-- From nobody Tue Feb 9 11:38:58 2021 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 7F1453A11E7 for ; Tue, 9 Feb 2021 11:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 ONJIw2TgHhj4 for ; Tue, 9 Feb 2021 11:38:51 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA73B3A11C1 for ; Tue, 9 Feb 2021 11:38:50 -0800 (PST) Received: from [192.168.1.11] ([90.79.54.243]) by mwinf5d85 with ME id T7em240055Eqqlm037em6A; Tue, 09 Feb 2021 20:38:49 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 09 Feb 2021 20:38:49 +0100 X-ME-IP: 90.79.54.243 From: Denis To: "txauth@ietf.org" Message-ID: Date: Tue, 9 Feb 2021 20:38:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------9DC75FCEEE3B9BC41653C30E" Content-Language: en-GB Archived-At: Subject: [GNAP] GNAP revisited X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 19:38:57 -0000 This is a multi-part message in MIME format. --------------9DC75FCEEE3B9BC41653C30E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit *GNAP revisited* The current GNAP draft does not take into consideration *RS Discovery* and *User Consent*, nor privacy requirements. This email explains why they should be taken into consideration. Before of speaking about implementation details, it is necessary to define a model and to identify the end-user requirements on that model. Such requirements are both /security /related and /privacy /related. *The basic eID model* The basic model is a Client-Server model which has two components: -An *end-user* which interacts with the network using a *Client* which a software and an hardware component running on a local device (e.g. on the end-user’s computer or the end-user's mobile phone). -A *Resource Server* (RS) that protects a resource within a server. *First security requirement* Most of the cases, an end-user is willing to open an account on a Resource Server and wants to be the single individual to have access to that account. For doing this, he does not need to present an access token from some Authorization Server (AS) but only needs to strongly authenticate to the RS. *First privacy requirement* >From an end-user perspective, it is necessary to prevent the linkability of transactions of an end-user among distinct resource servers (or even within a single resource server). This property is called unlinkability. *Taking into consideration these two requirements* A well known mechanism has been promoted by the FIDO Alliance. It provides strong authentication by using asymmetric keys instead of passwords and also considers an end-user privacy requirement: in order to prevent the linkability of transactions of an end-user among different resource servers, a different pseudonym is being used for every resource server. As a result, an end-user can open a user account on a resource server using a pseudonym and a key pair. This account may be permanent or temporary. In both cases, it is thus possible prevent the linkability of transactions of an end-user among distinct servers or even for the same server. A FIDO client can be implemented either using software-only or using a combination of software and hardware (e.g using both a secure element and a web browser). *The basic eID model enhanced with access tokens* Most of the time, an end-user is opening a user account on a RS to deposit some data, to get some data or to perform transactions. There are cases where, in order to get a specific operation fulfilled, it is needed to present some privileges or access rights granted by one or more ASs. It is not always necessary to present such granted privileges or access rights for every operation or access. The RS may request to present such access tokens that contains these attributes once a day, a week, a month, a quarter or a year, depending upon his access control policy for the resource being operated. Neither the client nor the end-user can anticipate when such access tokens are necessary. This will depend upon the operation the end-user wants to perform. In order to be able to know whether access tokens are needed and, if needed, which access tokens are needed, the client needs to first advertise the operation that it is willing to perform and then get the choice to continue or to discontinue the operation. This is why a *RS Discovery* mechanism is needed. Following this RS discovery phase, from a privacy point of view, it is fundamental get the *User Consent*. The end-user may consent to request access tokens from some of the advertised AS (which are the ASs trusted by the RS for the specific requested operation). If some access tokens which are still valid have been cached by the Client, this may avoid to request fresh access tokens. The enhanced model which has now three components needs to take into consideration both "Privacy by Design" (PbD) principles and "privacy by default". Additional privacy requirements >From an end-user perspective, it is important : (a)to minimize the amount of attributes being disclosed by an end-user to the minimum necessary to achieve a stated purpose (Data minimization), (b) to control that the obtained access token only contains the requested attributes (Transparency), (c)to prevent an Authorization Server to know to which Resource Server an access token will be presented by the Client (Untraceability). (d)  to prevent an Authorization Server to know /which /operation(s) will be performed by the Client on a RS, (e) to prevent an Authorization Server to know /when /operation(s) are being performed by a Client on a RS. These five additional privacy requirements need to be considered when constructing an eID mechanism. Taking into consideration the six privacy requirements *User Consent*: In order to enable users to agree to consent for the communication of their attributes through an affirmative process, the end-user should be able to select the attributes he would like to be placed into an access token. *Data minimization *: In order to minimize the amount of attributes being disclosed by a user to the minimum necessary to achieve a stated purpose, an access token should only contain the set of attributes that is needed. *Transparency*: The client should be able to verify which attributes have effectively been placed in an access token by an Authorization Server before forwarding it to a Resource Server. As an example,if the access token is considered to be opaque to the client, this requirement cannot be fulfilled. *Untraceability*: In order to prevent an Authorization Server to know to which Resource Server an access token will be presented by the Client: 1there shall be no direct interaction between an Authorization Server and a Resource Server, and 2the access token shall not contain data that would allow the Authorization Server to identify the Resource Server. This last condition is rather important otherwise Authorization Servers would have the possibility to act as "Big Brother". As an example, when capabilities are supported by an Authorization Server it isnot possible meet this requirement. The Authorization Server should not be able to know /which /operation(s) may be performed by the Client on a RS. As an example, when capabilities are supported by an Authorization Server it isnot possible meet this requirement. The Authorization Server should not be able to know /when /operation(s) are being performed by the Client on a RS. As an example, the existence of "Token Introspection" mechanism (as defined in OAuth) is unable to fulfil this requirement. Taking into consideration FIDO FIDO can be implemented without or with secure elements. There are both advantages and disadvantages to use secure elements. When secure elements are being used, they do not need to be provided by a governmental agency. they can be provided by any manufacturer and distributed by anyone, e.g. sold in a supermarket. Such secure elements do not originally contain any personal data. If secure elements are being used, Authorizations Servers would be able to verify that they interact with a client using a secure element. This opens a Pandora box for additional opportunities, in particular the direct verification by the Authorizations Servers of APDUs (Application Protocol Data Units) generated by the secure elements. Conclusion This approach highlights the fact that operations can be performed on a resource server (RS) *with or without using access tokens * and that two major operations need to be supported: *RS Discovery* and *User Consent*. This approachis able to support six privacy requirements. This approach is also able to take advantage of a technology supported by some major vendors: *FIDO*. Denis --------------9DC75FCEEE3B9BC41653C30E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 
    GNAP revisited
    The current GNAP draft does not take into consideration RS Discovery and User Consent, nor privacy requirements.
This email explains why they should be taken into consideration.

Before of speaking about implementation details, it is necessary to define a model and to identify the end-user requirements 
on that model. Such requirements are both security related and privacy related.

    The basic eID model

    The basic model is a Client-Server model which has two components:

    -          An end-user which interacts with the network using a Client which a software and an hardware component running on a local device
    (e.g. on the end-user’s computer or the end-user's mobile phone).

    -          A Resource Server (RS) that protects a resource within a server.

    First security requirement

    Most of the cases, an end-user is willing to open an account on a Resource Server and wants to be the single individual to have access to that account.
    For doing this, he does not need to present an access token from some Authorization Server (AS) but only needs to     strongly authenticate to the RS.

    First privacy requirement

    From an end-user perspective, it is necessary to prevent the linkability of transactions of an end-user among distinct resource servers
    (or even within a single resource server). This property is called unlinkability    .

    Taking into consideration these two requirements

    A well known mechanism has been promoted by the FIDO Alliance. It provides strong authentication by using asymmetric keys
    instead of passwords and also considers an end-user privacy requirement: in order to prevent the linkability of transactions of an end-user
    among different resource servers, a different pseudonym is being used for every resource server.

    As a result, an end-user can open a user account on a resource server using a pseudonym and a key pair. This account may be permanent
    or temporary. In both cases, it is thus possible prevent the linkability of transactions of an end-user among distinct servers or even for the same server.

    A FIDO client can be implemented either using software-only or using a combination of software and hardware (e.g using both a secure element and a web browser).

    The basic eID model enhanced with access tokens

    Most of the time, an end-user is opening a user account on a RS to deposit some data, to get some data or to perform transactions.

    There are cases where, in order to get a specific operation fulfilled, it is needed to present some privileges or access rights granted by one or more ASs.
    It is not always necessary to present such granted privileges or access rights for every operation or access. The RS may request to present such access tokens
    that contains these attributes once a day, a week, a month, a quarter or a year, depending upon his access control policy for the resource being operated.

    Neither the client nor the end-user can anticipate when such access tokens are necessary. This will depend upon the operation the end-user wants to perform.
    In order to be able to know whether access tokens are needed and, if needed, which access tokens are needed, the client needs to first advertise the operation
    that it is willing to perform and then get the choice to continue or to discontinue the operation.

    This is why a RS Discovery mechanism is needed.

    Following this RS discovery phase, from a privacy point of view, it is fundamental get the User Consent.

    The end-user may consent to request access tokens from some of the advertised AS (which are the ASs trusted by the RS for the specific requested operation).

    If some access tokens which are still valid have been cached by the Client, this may avoid to request fresh access tokens.

    The enhanced model which has now three components needs to take into consideration both "Privacy by Design" (PbD) principles and "privacy by default".

    Additional privacy requirements

    From an end-user perspective, it is important :

    (a)  to minimize the amount of attributes being disclosed by an end-user to the minimum necessary to achieve a stated purpose (Data minimization),

    (b)  to control that the obtained access token only contains the requested attributes (Transparency),

    (c)  to prevent an Authorization Server to know to which Resource Server an access token will be presented by the Client (Untraceability).

    (d)  to prevent an Authorization Server to know which operation(s) will be performed by the Client on a RS,

    (e)  to prevent an Authorization Server to know when operation(s) are being performed by a Client on a RS.

    These five additional privacy requirements need to be considered when constructing an eID mechanism.

    Taking into consideration the six privacy requirements

    User Consent : In order to enable users to agree to consent for the communication of their attributes through an affirmative process,
    the end-user should be able to select the attributes he would like to be placed into an access token.

    Data minimization : In order to minimize the amount of attributes being disclosed by a user to the minimum necessary to achieve a stated purpose,
    an access token should only contain the set of attributes that is needed.

    Transparency : The client should be able to verify which attributes have effectively been placed in an access token by an Authorization Server
    before forwarding it to a Resource Server.     As an example,if the access token is considered to be opaque to the client, this requirement cannot be fulfilled.

    Untraceability : In order to prevent an Authorization Server to know to which Resource Server an access token will be presented by the Client:

    1        there shall be no direct interaction between an Authorization Server and a Resource Server, and

    2        the access token shall not contain data that would allow the Authorization Server to identify the Resource Server.

    This last condition is rather important otherwise Authorization Servers would have the possibility to act as "Big Brother".
    As an example, when capabilities are supported by an Authorization Server it is not possible meet this requirement.

    The Authorization Server should not be able to know which operation(s) may be performed by the Client on a RS.
    As an example, when capabilities are supported by an Authorization Server it is not possible meet this requirement.

    The Authorization Server should not be able to know when operation(s) are being performed by the Client on a RS.
    As an example, the existence of "Token Introspection" mechanism (as defined in OAuth) is unable to fulfil this requirement.

    Taking into consideration FIDO

    FIDO can be implemented without or with secure elements. There are both advantages and disadvantages to use secure elements.

    When secure elements are being used, they do not need to be provided by a governmental agency. they can be provided by any manufacturer
    and distributed by anyone, e.g. sold in a supermarket. Such secure elements do not originally contain any personal data.

    If secure elements are being used, Authorizations Servers would be able to verify that they interact with a client using a secure element.
    This opens a Pandora box for additional opportunities, in particular the direct verification by the Authorizations Servers of APDUs
    (Application Protocol Data Units) generated by the secure elements.

    Conclusion

    This approach highlights the fact that operations can be performed on a resource server (RS) with or without using access tokens
    and that two major operations need to be supported: RS Discovery and User Consent.     This approach is able to support six privacy requirements.

    This approach is also able to take advantage of a technology supported by some major vendors: FIDO.

    Denis


    --------------9DC75FCEEE3B9BC41653C30E-- From nobody Wed Feb 10 04:20:01 2021 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 897093A0E2F for ; Wed, 10 Feb 2021 04:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 zH05sjYBYkSN for ; Wed, 10 Feb 2021 04:19:59 -0800 (PST) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE6F3A0E2E for ; Wed, 10 Feb 2021 04:19:55 -0800 (PST) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 11ACJZpP019742 for ; Wed, 10 Feb 2021 07:19:54 -0500 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 10 Feb 2021 07:19:40 -0500 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 10 Feb 2021 07:19:40 -0500 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Wed, 10 Feb 2021 07:19:40 -0500 From: Justin Richer To: "TxAuth@ietf.org" Thread-Topic: Pending merge: Removing grant read Thread-Index: AQHW/6cBKUey9bod50+54M0IHX6BaA== Date: Wed, 10 Feb 2021 12:19:40 +0000 Message-ID: <0909f0970196409baade6330c0f87589@oc11expo18.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [GNAP] Pending merge: Removing grant read X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 12:20:01 -0000 As posted to the list last week, a pull request to close issues #98 and #99= has been posted and reviewed, and is now marked Pending Merge. https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/170 - Justin, Fabien, and Aaron= From nobody Wed Feb 10 07:31:53 2021 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 8642C3A0DCC for ; Wed, 10 Feb 2021 07:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 ETJGOSid5jp6 for ; Wed, 10 Feb 2021 07:31:50 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D651B3A0DC6 for ; Wed, 10 Feb 2021 07:31:49 -0800 (PST) Received: from [192.168.1.11] ([90.79.54.243]) by mwinf5d41 with ME id TTXl240045Eqqlm03TXltV; Wed, 10 Feb 2021 16:31:47 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 10 Feb 2021 16:31:47 +0100 X-ME-IP: 90.79.54.243 To: "txauth@ietf.org" References: <16581957-CEEB-41D7-87F3-CFDF24056750@gmail.com> From: Denis Message-ID: <7b6ae4c8-a0be-c415-c895-8c648fbe8bb9@free.fr> Date: Wed, 10 Feb 2021 16:31:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <16581957-CEEB-41D7-87F3-CFDF24056750@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [GNAP] Using GitHub in the context of GNAP X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 15:31:52 -0000 At the last interim meeting on January the 12 th, concerns were expressed that using GitHub for GNAP was not that easy for everybody. Fabien proposed to present GitHub for GNAP using a webinar. I send a private email to him saying that a document with screen shots and instructions would be much better. Nevertheless, at this time, no information at all has been released. At the moment, I am unable to raise a comment. I even have difficulties to get a formatted document that I can process using MS Word. Would someone from the WG be able to help ? Thanks, Denis PS. If would be nice, if we could address this issue during the call from today. From nobody Wed Feb 10 07:44:37 2021 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 EE29C3A0E27 for ; Wed, 10 Feb 2021 07:44:35 -0800 (PST) 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 QP-kWoeyMEBR for ; Wed, 10 Feb 2021 07:44:34 -0800 (PST) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 6EDC23A0E29 for ; Wed, 10 Feb 2021 07:44:34 -0800 (PST) Received: by mail-il1-x134.google.com with SMTP id e7so2234251ile.7 for ; Wed, 10 Feb 2021 07:44:34 -0800 (PST) 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=ef4NqxLiuLK7ZiP593RaD86hH/CZEhRWwn0bgnufgUY=; b=rVhc56ZpKsXwL+FGQJHM8bAzlgtJ+4NfNPOrgk1UVJAhamYTn3NtDJQcPZ18VILJut H9gUyia3XPOp6ANCcM3nKs5nR8w28w8HxnnNmaBQD2hBV8BfyshVKj9yWPG7X2DCpdYC UmC5+MxthmEE+/HlkFe/IsNv/Fb47wgCnxGk8b/626NPBHiRlYvWxcl5SeIz7atWtD+g CHeTGKVPLIFiHi5IoUyjauqHiAwD/Hbg0OqY/KYC0ac9IpD9ZBBI4bZZdq/S6oDS3PsH TExdNvzvPeTEmbQcUzDx715qHeaaQLUJhplGkNzq7Nj3W2vxYiQlBNKj3XCLgBYMSWZ5 h0FA== 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=ef4NqxLiuLK7ZiP593RaD86hH/CZEhRWwn0bgnufgUY=; b=GMrdk2n/YyUSrmub7xolMvWs2Wnd/iS2SwV4Cv2ZAWGT2eYa746OxXsKnasgs+cWxy oq9aRl/RLTG5HQQmBeCUajdXO95Nb7QTjcosO8o5Wrj6lXXjGPJPi+Z62e7Svdai7RWj WaRTLakicS2OMfiCYVYlbmiUjwrF418KdNoWr1d9q2zjxqBDg5aW4FziNUFOo+ZaytFK Zsx1tuc0n/VMs/6xjbrzmuA1ZuHnH0JXbIwWPZ7VJ7JXJSiCvBZJRTr5T+PCcH8FXiE6 Co2iL+wonEJtq3VWp8inC1df5S+dwgUU2D/g3S7yCSt4EzZ0/jZ3dLDEGSZFkqMvwK+H sNow== X-Gm-Message-State: AOAM531ZXhpHDoFRtQReqEHNPDzdd8pe7G1+BqQv+2qfNKYAUaZhrzxX zPQdXmgQ+GC/h+sNGx3DGCr8zH5mbPi/pTEqPkfkBUX+OtyX1A== X-Google-Smtp-Source: ABdhPJysOpgqgeubdKvUUbqXiVaROi10VjCNNFRZDGUEwZtuwJ+aMHbWEJJvU3mXfiGO81gPUZti9+kdDiA1eCOz65U= X-Received: by 2002:a05:6e02:1a89:: with SMTP id k9mr1637893ilv.68.1612971873546; Wed, 10 Feb 2021 07:44:33 -0800 (PST) MIME-Version: 1.0 References: <16581957-CEEB-41D7-87F3-CFDF24056750@gmail.com> <7b6ae4c8-a0be-c415-c895-8c648fbe8bb9@free.fr> In-Reply-To: <7b6ae4c8-a0be-c415-c895-8c648fbe8bb9@free.fr> From: Fabien Imbault Date: Wed, 10 Feb 2021 16:44:21 +0100 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008e371405bafd4715" Archived-At: Subject: Re: [GNAP] Using GitHub in the context of GNAP X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 15:44:36 -0000 --0000000000008e371405bafd4715 Content-Type: text/plain; charset="UTF-8" Hi Denis, You've got a complete wiki available https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Github-tutorial Fabien On Wed, Feb 10, 2021 at 4:31 PM Denis wrote: > > At the last interim meeting on January the 12 th, concerns were > expressed that using GitHub for GNAP was not that easy for everybody. > Fabien proposed to present GitHub for GNAP using a webinar. I send a > private email to him saying that a document with screen shots > and instructions would be much better. > > Nevertheless, at this time, no information at all has been released. At > the moment, I am unable to raise a comment. > I even have difficulties to get a formatted document that I can process > using MS Word. > > Would someone from the WG be able to help ? > > Thanks, > > Denis > > PS. If would be nice, if we could address this issue during the call > from today. > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000008e371405bafd4715 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Denis,=C2=A0


    Fabien

    On We= d, Feb 10, 2021 at 4:31 PM Denis <= denis.ietf@free.fr> wrote:

    At the last interim meeting on January the 12 th, concerns were
    expressed that using GitHub for GNAP was not that easy for everybody.
    Fabien proposed to present GitHub for GNAP using a webinar. I send a
    private email to him saying that a document with screen shots
    and instructions would be much better.

    Nevertheless, at this time, no information at all has been released. At the moment, I am unable to raise a comment.
    I even have difficulties to get a formatted document that I can process using MS Word.

    Would someone from the WG be able to help ?

    Thanks,

    Denis

    PS. If would be nice, if we could address this issue during the call
    from today.

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000008e371405bafd4715-- From nobody Thu Feb 11 05:22:41 2021 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 5D4CA3A0E87 for ; Thu, 11 Feb 2021 05:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.505 X-Spam-Level: X-Spam-Status: No, score=-0.505 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, MALFORMED_FREEMAIL=1.591, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 7O_DcmK7sZwN for ; Thu, 11 Feb 2021 05:22:39 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 B095A3A0E7E for ; Thu, 11 Feb 2021 05:22:38 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id n10so3854077wmq.0 for ; Thu, 11 Feb 2021 05:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=+BzxxZw4+iblT5GFWro9zYKW7Esrf4tYQbGi+lcYij8=; b=TLdZ8lJU6aefB+vN0owrb+55w1BdlUbbtNbWBk476ZFgw7PhefIrOHIYOo8xaPjKoZ h9uYu+zpaQ3OB+sRIEfHW0ci7t2k+Nj/DNNGgtPK6EiL/Gf+1/OTzqCKYqCqDO9nuqOt XD8ev24IjJPajbE9or2UzE/FsY9Nm4K1aRUWIRb3vMQME6/MdfsaQco1od6x05xAZ2Bn /oetOolwxZJTx2RXWUH1V2j36eoeZHsrQJ/erJf7511oYI5uo90AlESkWCujmmmVSP/r 7knWVlh+zcTsPJQWVSTPduPRv+Vq0cuS5Snm46YHta1/12Ko1zOhSMkfLpYZ3OpsmBVz m3RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=+BzxxZw4+iblT5GFWro9zYKW7Esrf4tYQbGi+lcYij8=; b=Kw4dsbhyNelDarI6OzKt7V69JFplax4L/oXK9uLe48p3YxO4vVRh4HGzX209AGU7sz dZaPn+1zFTK3l2e3Zb6Tq8AiplJTLSXPwFLYVZvkdlP120JDtDrnbpNpa8Sz7r4PB3pK gqeLQBPJEJ/u0nT9dCPmz0pZJgSb79DSDDgrnVTCFvCvKoTvNERJJF9/EXHRc9vW9AXN sQiR3PBfjArzonOGh1mvSRZ65UdZjbntc3ODpfQd8UZb71gq6A5kzmI4fiOu3Ob7tvDR BACm8ktzVH02sTI1/Np9ho69icrokAvbx4H5457UrOLYLLxVsD9Ism1dU+vSWhmMavRG J+dw== X-Gm-Message-State: AOAM531ZZp07+ArWJWIXe0NEvSxI+gLdm8yI3PA5wDFIh63zxI21/CHJ qtWSC3Vs/bRdv1jmmVNOIv6P4mWiwPmrVA== X-Google-Smtp-Source: ABdhPJzRztnN0pmkWzWJE2aUenuXfhISIKSf2RiTzYIT7K1gRcWc9xVVjA7AIlgFnR+Aaaszwc63Jw== X-Received: by 2002:a1c:c308:: with SMTP id t8mr5257989wmf.7.1613049751955; Thu, 11 Feb 2021 05:22:31 -0800 (PST) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id a17sm5250051wrx.63.2021.02.11.05.22.30 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Feb 2021 05:22:31 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.45.21011103 Date: Thu, 11 Feb 2021 15:22:29 +0200 From: Yaron Sheffer To: GNAP Mailing List Message-ID: Thread-Topic: GNAP interim recording Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3695901750_920740882" Archived-At: Subject: [GNAP] GNAP interim recording X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 13:22:40 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3695901750_920740882 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable In case you missed yesterday=E2=80=99s meeting: =20 https://intuit.zoom.us/rec/share/QgYbO91aTYO0o35cEr1z6hXtCUjfMedkykfNm2iOF0= gI7VmO3PcsvmVVzgeNgogm.c91IPxDIoybJYO_B=20 =20 Passcode: e^r8u8Q=3D=20 =20 We will share formal minutes shortly. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron --B_3695901750_920740882 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

    In case you missed yesterday=E2=80=99s meeting:

     

    h= ttps://intuit.zoom.us/rec/share/QgYbO91aTYO0o35cEr1z6hXtCUjfMedkykfNm2iOF0gI= 7VmO3PcsvmVVzgeNgogm.c91IPxDIoybJYO_B

    =  

    Passcode: e^r8u8Q=3D

     

    We will share forma= l minutes shortly.

     

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Yaron

    --B_3695901750_920740882-- From nobody Thu Feb 11 06:37:29 2021 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 A0D1C3A162E for ; Thu, 11 Feb 2021 06:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.505 X-Spam-Level: X-Spam-Status: No, score=-0.505 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, MALFORMED_FREEMAIL=1.591, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 HONpA-Pzr4kj for ; Thu, 11 Feb 2021 06:37:27 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 0FD333A162F for ; Thu, 11 Feb 2021 06:37:27 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id z6so4369706wrq.10 for ; Thu, 11 Feb 2021 06:37:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=FZ//o7gcbeJ4p82xNeJtl3kyshafKcP/LqHWvmJ6V2I=; b=bDKTjxFy2mSwUkLpCEHra3eYZL63HY8REuAfsfF220J0r/Ec+APX3oP1yGhIFbow1F 2dfQKsuGzkRu7jGvipoIrMZjnd+I/xncRLRuxWs9RKQAOkhF6aD6jJ26qaoKR256dCUg bd6lDEa9Ec3qlFZf4zqsMD+fRMM/YMcwxQn8e26ALv47a4zQwMvUs166qTuuvvDb7Aqx QiQMysvn+vNDzSozMduoygEMAVaYomvI8D/zdH8OhXN6b5sSMVmYbGKoc5u+XSbQ4eO0 hm6qoPJf76NeWk1z737rOyM7eYJDnSR5vnQDLe+A/yawJYqjcX29HDRLgxHYMow2stbE JXIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=FZ//o7gcbeJ4p82xNeJtl3kyshafKcP/LqHWvmJ6V2I=; b=idhzUP3kUb/rRqb+csa43WR2UVcJNggPAYgmZrHKC/wsLkyoGf7VYlDu7iBxynUvV6 I8Ez/hf+AgVljaN2emjZSGsurZBVwElXtSIw8hX9by05KX+n9cYRW7PJbloC0RrymD6Z gAORLxWiMMBVOrXUNRSVyE0MOG+vDs2YUQnTb6+e7CJ99OsbaV0b7cMLQrWEgkzI3ueH NsfHQXs9tMJf0mNyYcujg8huXNtHyNizD6mYaRjXXFbAYBsHb54V5MR+P3Lyc/NQtc/e oRyVUmx+07SYhoKDbG5AMEdW1KCJuJAmf4eDzt7chXyYEb33isSud1JwcgnPuRet0JMe Wqew== X-Gm-Message-State: AOAM532ca/enyIUTkyY5ikkEE7I2eP06XbjhEFjg9IYb3JGSeVMCumw+ DZQqXQJRjn2MCtzFtPBnKIDCPNVvgbk5Dg== X-Google-Smtp-Source: ABdhPJzpeTOrRghQZkVa7guWuuzkEsKIAn3FbeFrRIPiIp/ISFUcB1RNOiUqD0eI/gHWGH4LfxN+WQ== X-Received: by 2002:a5d:5248:: with SMTP id k8mr6083468wrc.17.1613054235108; Thu, 11 Feb 2021 06:37:15 -0800 (PST) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id d5sm5727284wrb.14.2021.02.11.06.37.13 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Feb 2021 06:37:14 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.45.21011103 Date: Thu, 11 Feb 2021 16:37:12 +0200 From: Yaron Sheffer To: GNAP Mailing List Message-ID: <1DA44342-32EC-4FB6-A9F1-A7E47383458F@gmail.com> Thread-Topic: GNAP interim recording References: <1D6F9006-B64A-4E1A-919E-D79361BC4FA1@gmail.com> In-Reply-To: <1D6F9006-B64A-4E1A-919E-D79361BC4FA1@gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3695906233_584452773" Archived-At: Subject: Re: [GNAP] GNAP interim recording X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 14:37:29 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3695906233_584452773 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I uploaded the minutes: https://datatracker.ietf.org/meeting/interim-2021-g= nap-02/session/gnap =20 Thank you Adrian for taking notes! =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Yaron Sheffer Date: Thursday, February 11, 2021 at 15:22 To: GNAP Mailing List Subject: GNAP interim recording =20 In case you missed yesterday=E2=80=99s meeting: =20 https://intuit.zoom.us/rec/share/QgYbO91aTYO0o35cEr1z6hXtCUjfMedkykfNm2iOF0= gI7VmO3PcsvmVVzgeNgogm.c91IPxDIoybJYO_B=20 =20 Passcode: e^r8u8Q=3D=20 =20 We will share formal minutes shortly. =20 Thanks, Yaron --B_3695906233_584452773 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

    I uploaded the minutes: https://datatracker.ietf.org/mee= ting/interim-2021-gnap-02/session/gnap

     

    Thank you Adrian for taking notes!

    &= nbsp;

    =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

     

    From: Yaron Sheffer <yaronf.ietf@gmail.com>
    Date: Thursday, Febru= ary 11, 2021 at 15:22
    To: GNAP Mailing List <txauth@ietf.org>= ;
    Subject: GNAP interim recording

    =

     

    In case you missed= yesterday=E2=80=99s meeting:

     

    https://intuit.zoom.us/rec/share/QgYb= O91aTYO0o35cEr1z6hXtCUjfMedkykfNm2iOF0gI7VmO3PcsvmVVzgeNgogm.c91IPxDIoybJYO_= B

     

    Passcode: e^r8u8Q=3D

     

    We will share formal minutes shortly.

     

    Thanks,

             &= nbsp;  Yaron

    --B_3695906233_584452773-- From nobody Fri Feb 12 16:37:16 2021 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 546B43A122E; Fri, 12 Feb 2021 16:33:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rdd@cert.org, txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317641032.31337.16043933902164611848@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:30 -0800 Archived-At: Subject: [GNAP] gnap - Requested session has been scheduled for IETF 110 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 00:33:38 -0000 Dear Yaron Sheffer, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. gnap Session 1 (2:00 requested) Tuesday, 9 March 2021, Session III 1700-1900 Room Name: Room 8 size: 508 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/sessions/gnap.ics Request Information: --------------------------------------------------------- Working Group Name: Grant Negotiation and Authorization Protocol Area Name: Security Area Session Requester: Yaron Sheffer Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: ace acme cose curdle dots emu i2nsf ipsecme kitten lake lamps mls rats sacm secdispatch secevent suit teep tls tokbind trans httpbis quic saag uta cfrg Technology Overlap: oauth People who must be present: Leif Johansson Roman Danyliw Yaron Sheffer Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Feb 13 23:56:18 2021 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 6E32C3A0FFD for ; Sat, 13 Feb 2021 23:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=b802WenP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cSpzkswl 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 Kl9NpjhMzSrq for ; Sat, 13 Feb 2021 23:56:10 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6988B3A100C for ; Sat, 13 Feb 2021 23:56:10 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id B677AB44 for ; Sun, 14 Feb 2021 02:37:00 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 14 Feb 2021 02:37:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=xsep1xSoTkBpN7UwoVsZCK9UhtMYPYrEKoxCfEsocSE=; b=b802WenP FVzHKlnyCl6n4NiyE3+OrDc/bxmZAS5rniYRGpkPnCmVwgfSeplDKQgX+GEOyrHb CmvixfT2EHJll9mGePEYzxlaT1agx93hILyLK4R3s36TbBtAo+byfaRh3SxCuhn8 7v/4l3cFWy/mjTaxGKCMozndPFC+fiE7hRrMDL4mQi+Wvz0n9RW5dOeGNGBYh3eZ 2ars3Q4hH6ReBwcNDuRKQ41mrKhd297jIo9x4SRWCAFpMwugJgCTmpKgcgm2iiLM JG7qcV0nmNOgiJJnVmDovaePgY6w171VyXnNo3i0VOhXgIfa1oRQtvXyPqlHfke1 ZsYn859n3i6lyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=xsep1xSoTkBpN7UwoVsZCK9UhtMYP YrEKoxCfEsocSE=; b=cSpzkswl1GSqQVMKB7sw/ufhwnIpkU6eHXpM6UxvugkUR 0ndAXMApridXbCXJadXqpzOaEhJC+7HDl3+lNUrQlb1PtLTT6oYZ/adrIFl42vcE WlpEn2rWe/09NS1fYYaqmy/cpy+adtV4aQrq5Qf9Ce+ZZEnB3Tn6PBB1giHJwP7S qdgUNh1coLmKIWYWcyYosNucqZdUi1csaEQPDB6ioy28DYO87KHlAytb6XotfRdh AluEtARPFcsgANkZkzUOnyCfse6h+/0dzFCISGvqR1FFDQTlcWqseysFC24TWvkr Zuvp239bSGyNp0i16L12vbzzK+8WXBKeFI2Sj3ytA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrieeggddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddvheegrdekhedrud dvfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az50-337.internal.cloudapp.net (unknown [52.254.85.123]) by mail.messagingengine.com (Postfix) with ESMTPA id 24E46108005B for ; Sun, 14 Feb 2021 02:36:59 -0500 (EST) Content-Type: multipart/alternative; boundary="===============3921930995688231335==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210214073659.24E46108005B@mailuser.nyi.internal> Date: Sun, 14 Feb 2021 02:36:59 -0500 (EST) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 07:56:12 -0000 --===============3921930995688231335== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-gnap/core-protocol (+7/-4/=F0=9F=92=AC16) 7 issues created: - grant_request_endpoint, HTTPS and fragment component (by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/180=20 - sub_ids and different contexts (by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/178=20 - Protocol rationale (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/176=20 - GNAP for Custodial SSI Wallets (by agropper) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175=20 - Add access token hash to DPoP (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/174=20 - Rename DPoP digest parameter (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/173=20 - subject identifiers as portable identifiers (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/171=20 6 issues received 16 new comments: - #175 GNAP for Custodial SSI Wallets (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175=20 - #173 Rename DPoP digest parameter (2 by fimbault, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/173=20 - #146 Persistent Grant Identifier (3 by davidgtonge, fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/146=20 - #145 Opaque / Non opaque access token (8 by agropper, fimbault, jricher= , yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145=20 - #122 Group interaction mode flags (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/122=20 - #104 Token presentation headers (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/104=20 4 issues closed: - Syntax of Flags https://github.com/ietf-wg-gnap/gnap-core-protocol/issu= es/13=20 - Token flags https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/3= 9=20 - Single vs. Multiple Access Tokens https://github.com/ietf-wg-gnap/gnap-= core-protocol/issues/10=20 - Access token request format https://github.com/ietf-wg-gnap/gnap-core-p= rotocol/issues/40=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+4/-3/=F0=9F=92=AC10) 4 pull requests submitted: - Fix typos. (by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/179=20 - Update draft-ietf-gnap-core-protocol.md (by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/177=20 - cleanup closed links (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/172=20 - closing issue 98, effectively removing section 5.4 (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/170=20 4 pull requests received 10 new comments: - #179 Fix typos. (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/179=20 - #177 Update draft-ietf-gnap-core-protocol.md (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/177=20 - #172 cleanup closed links (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/172 [Editorial]= =20 - #170 closing issue 98, effectively removing section 5.4 (7 by davidgton= ge, fimbault, jricher, netlify, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/170 [Pending Me= rge]=20 3 pull requests merged: - cleanup closed links https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/172 [Editorial]= =20 - Replace 'MUST ... if possible' with SHOULD. https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/143 [Pending Me= rge]=20 - Reformat access token request and response format. https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/162 [Pending Me= rge]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============3921930995688231335== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (GNAP Weekly GitHub Activity Summary)

    Sunday February 14, 2021

    Events without label "editorial"

    Issues

    ietf-wg-gnap/core-protocol (+7/-4/=F0=9F=92=AC16)

    7 issues created:

    6 issues received 16 new comments:

    4 issues closed:

    Pull requests

    ietf-wg-gnap/core-protocol (+4/-3/=F0=9F=92=AC10)

    4 pull requests submitted:

    4 pull requests received 10 new comments:

    3 pull requests merged:

    Repositories tracked by this digest:

    --===============3921930995688231335==-- From nobody Sun Feb 14 01:12:24 2021 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 E49B63A1823 for ; Sun, 14 Feb 2021 01:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 tdZ_otTuxWVq for ; Sun, 14 Feb 2021 01:12:20 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 7FCCD3A181D for ; Sun, 14 Feb 2021 01:12:20 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id y15so3086003ilj.11 for ; Sun, 14 Feb 2021 01:12:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xx3ok6RvsOKnS6bYmc7g9GG7Og2R1OsRRCcHiuV7yBc=; b=njHzj8wE3KRPkoRI5qMZP2/RNbIFeO4T5z+Tfp3iu2rOkDGHzHY0MSL3tu0T1BoERD uAohiawAFw9j7TRPZS3yqR/e1AGXj2eOm5VMHsQrIQ0p4A01uru2fd6acHOHqQ+TjK2F yI0KhW7nm+5K+pQSrqT69gbzOfd/XHxq9jua+BldcR6AbqwgpyfvHhpDs9YIfHDY5Z6V Xd4gbsyD16eWr2NBfwUFH4cQzdf/ng4bkYbiUy45PShtyqL2MAwqn/c9SR6SHCWtySF/ Tf0Ha/kqL4e5CgG1K940vWyAjAnvZy0tO3c5adOTApOUNsOa68PHafp+riuD9astOO08 Z8vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xx3ok6RvsOKnS6bYmc7g9GG7Og2R1OsRRCcHiuV7yBc=; b=dIslqQxNuCuc5/Ss2H795ffwdvnhh10YmQEfVihXrl1ElrsyV3WWKole1t7GxK7tMu eb684lyuOlQplgS9euSkfMLrkA7BfeaDQwI/4TAfv1QehkMgGBoIFDXcq+oq3FmYWwPh kr2cEILLm7lX8RH90ryVj4bNdYi+bLK1mNO7lbk4ciS1/YJ3S7GXvDtKjmIkt3Ft5WW/ xaMrtUsctTWtZanXR1w8mSiSGqOq9WcTaG4RLR/5z+O/gFP0XHtO+vF2GT2biFIMJ2lo 641/Buks6sN+01mYuoUHCPIy+yRWhPPqbaeAR+p8a3WCy7RisHGj4t4/4j2/WvozKVS5 7LVg== X-Gm-Message-State: AOAM532c6IIhH2si9J6Z4LPrGm+k2NTrXiZaGJMm6xJZzc+2WJQQc/qB BapAgl2KjsUipSfckOgyzVabPyDDaD7fWs34u10pUNPwai7CtA== X-Google-Smtp-Source: ABdhPJwoHzSkQlYEo3rrVApU3scozJ0mfWDUsv6pSWXXhuH2FVsHY2XTldqssok8UWCY8WQRzNQaMBol8WjVznEj+mM= X-Received: by 2002:a05:6e02:1cac:: with SMTP id x12mr9428693ill.188.1613293939498; Sun, 14 Feb 2021 01:12:19 -0800 (PST) MIME-Version: 1.0 From: Fabien Imbault Date: Sun, 14 Feb 2021 10:12:08 +0100 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000002ea58805bb484443" Archived-At: Subject: [GNAP] Wiki on subject identifiers X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 09:12:22 -0000 --0000000000002ea58805bb484443 Content-Type: text/plain; charset="UTF-8" Hi everyone, As highlighted in the last interim call, one of the items we'll try to cover soon is subject identifiers. Since there are many issues related to that topic, we figured it would be helpful to group the open questions into a single place. Available from https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Subject (or from my personal hackmd, easier for editing markdown https://hackmd.io/uuq0zv8kSA-VKjbvW6-x-g) Cheers Fabien --0000000000002ea58805bb484443 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi everyone,=C2=A0

    As highlighted i= n the last interim call, one of the items we'll try to cover soon is su= bject identifiers.=C2=A0
    Since there are many issues related to t= hat topic, we figured it would be helpful to group the open questions into = a single place.=C2=A0

    Available from=C2=A0https:= //github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Subject (or from my p= ersonal hackmd, easier for editing markdown https://hackmd.io/uuq0zv8kSA-VKjbvW6-x-g)=C2=A0

    Cheers
    Fabien
    --0000000000002ea58805bb484443-- From nobody Wed Feb 17 14:27:36 2021 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 CB8E53A1DE7 for ; Wed, 17 Feb 2021 14:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 eS3dzxnROGt2 for ; Wed, 17 Feb 2021 14:27:32 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928293A1DE4 for ; Wed, 17 Feb 2021 14:27:32 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11HMRURq013986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 17 Feb 2021 17:27:31 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_291CD9C6-E671-496A-8EA1-1F9212133B57" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <6C0CBD9E-BE9B-47F7-8361-25785DCFDC82@mit.edu> Date: Wed, 17 Feb 2021 17:27:30 -0500 To: txauth gnap X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 22:27:35 -0000 --Apple-Mail=_291CD9C6-E671-496A-8EA1-1F9212133B57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The last interim call had a lot of discussion on SSI technologies such = as digital wallets, and how those fit with GNAP. I think it=E2=80=99s = worth continuing that conversation here on the list. There are a few = issues in the tracker that give some background, too: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 = There=E2=80=99s been a lot of interesting work recently in the OpenID = Foundation around using the Self-issued OP (SIOP) functionality to = bootstrap an SSI style login. This makes extensive use of the implicit = flow and front channel messaging, but minimization of the front channel = for message passing is a key design tenet of GNAP (so much so that = it=E2=80=99s included in our charter). Instead, GNAP has been built = around an idea that everything starts the same way: with an HTTP request = to the AS.=20 The idea of an on-device AS has been brought up a lot, and we need to = consider if and how we want to deal with these kinds of use cases. The = most obvious way to address these would be to do some kind of clever = off-HTTP hack like SIOP, but keep in mind that even SIOP generally = starts off with an HTTP-based discovery call by the RP to make things = work. My personal stance is that to do this, we need to re-evaluate our = assumptions about exactly what an AS does and what it needs to do those = things. In OAuth 2, it=E2=80=99s assumed that the AS is the device = that=E2=80=99s authenticating the user, collecting consent, managing the = client=E2=80=99s registration, and creating an access token based on = whatever set of rights that are associated with all of those things. In = UMA, this is turned around a bit by letting the RO present a bunch of = nebulous =E2=80=9Cclaims=E2=80=9D interactively, but still at the AS.=20 With both of these, a key aspect remains: the AS needs to gather = necessary information, and issue the access token (or = identifiers/assertions). Because of how the protocol works, the client = software now has a better opportunity to present information to the AS, = either directly in the request or by introducing the AS to another = software component during the =E2=80=9Cinteraction=E2=80=9D phase. So, = what if we think of the AS primarily as a =E2=80=9Ctoken issuer=E2=80=9D?=20= For example, if the client can present a verifiable credential (VC) that = represents the end user, the AS can validate that VC and make an access = token on behalf of that user, without having the user log in or interact = with the AS at all. This VC can contain whatever access rights the token = needs to represent, and the AS can translate that into an artifact that = the downstream RS=E2=80=99s can interpret, without having to see the = original VC or the user at all. The AS is still HTTP based, but all the = essential security and rights elements are provided by the wallet. In = this way, we can expand on the privacy-preserving aspects of OAuth and = bridge the worlds of SSI and web APIs without violating the basic nature = of either. Coming from the OAuth world, it feels weird to issue tokens like this, = but there=E2=80=99s precedent for this kind of thing. Today, a there are = a number of service-based OAuth AS's that are told what claims need to = get put into the access token by some trusted component. All of this = happens outside the OAuth protocol. In GNAP, I think it makes sense to = account for this kind of thing in how we define the protocol. That = isn=E2=80=99t to say all of these pieces need to be defined in the core, = but the base protocol ought to be able to handle being extended in this = direction as needed. I=E2=80=99m really interested to hear other people=E2=80=99s thoughts on = how this could come together. =E2=80=94 Justin= --Apple-Mail=_291CD9C6-E671-496A-8EA1-1F9212133B57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = last interim call had a lot of discussion on SSI technologies such as = digital wallets, and how those fit with GNAP. I think it=E2=80=99s worth = continuing that conversation here on the list. There are a few issues in = the tracker that give some background, too:

    https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175

    There=E2=80=99s been a lot of interesting work recently in = the OpenID Foundation around using the Self-issued OP (SIOP) = functionality to bootstrap an SSI style login. This makes extensive use = of the implicit flow and front channel messaging, but minimization of = the front channel for message passing is a key design tenet of GNAP (so = much so that it=E2=80=99s included in our charter). Instead, GNAP has = been built around an idea that everything starts the same way: with an = HTTP request to the AS. 

    The idea of an on-device AS has been = brought up a lot, and we need to consider if and how we want to deal = with these kinds of use cases. The most obvious way to address these = would be to do some kind of clever off-HTTP hack like SIOP, but keep in = mind that even SIOP generally starts off with an HTTP-based discovery = call by the RP to make things work.

    My personal stance is that to do this, = we need to re-evaluate our assumptions about exactly what an AS does and = what it needs to do those things. In OAuth 2, it=E2=80=99s assumed that = the AS is the device that=E2=80=99s authenticating the user, collecting = consent, managing the client=E2=80=99s registration, and creating an = access token based on whatever set of rights that are associated with = all of those things. In UMA, this is turned around a bit by letting the = RO present a bunch of nebulous =E2=80=9Cclaims=E2=80=9D interactively, = but still at the AS. 

    With both of these, a key aspect remains: the AS needs to = gather necessary information, and issue the access token (or = identifiers/assertions). Because of how the protocol works, the client = software now has a better opportunity to present information to the AS, = either directly in the request or by introducing the AS to another = software component during the =E2=80=9Cinteraction=E2=80=9D phase. So, = what if we think of the AS primarily as a =E2=80=9Ctoken = issuer=E2=80=9D? 

    For example, if the client can present a verifiable = credential (VC) that represents the end user, the AS can validate that = VC and make an access token on behalf of that user, without having the = user log in or interact with the AS at all. This VC can contain whatever = access rights the token needs to represent, and the AS can translate = that into an artifact that the downstream RS=E2=80=99s can interpret, = without having to see the original VC or the user at all. The AS is = still HTTP based, but all the essential security and rights elements are = provided by the wallet. In this way, we can expand on the = privacy-preserving aspects of OAuth and bridge the worlds of SSI and web = APIs without violating the basic nature of either.

    Coming from the OAuth = world, it feels weird to issue tokens like this, but there=E2=80=99s = precedent for this kind of thing. Today, a there are a number of = service-based OAuth AS's that are told what claims need to get put into = the access token by some trusted component. All of this happens outside = the OAuth protocol. In GNAP, I think it makes sense to account for this = kind of thing in how we define the protocol. That isn=E2=80=99t to say = all of these pieces need to be defined in the core, but the base = protocol ought to be able to handle being extended in this direction as = needed.

    I=E2=80=99= m really interested to hear other people=E2=80=99s thoughts on how this = could come together.

     =E2=80=94 Justin
    = --Apple-Mail=_291CD9C6-E671-496A-8EA1-1F9212133B57-- From nobody Thu Feb 18 00:19:15 2021 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 EA52E3A0D9B for ; Thu, 18 Feb 2021 00:19:14 -0800 (PST) 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 laQAHBe9TGXn for ; Thu, 18 Feb 2021 00:19:12 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 C34133A0D99 for ; Thu, 18 Feb 2021 00:19:12 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id g9so763730ilc.3 for ; Thu, 18 Feb 2021 00:19:12 -0800 (PST) 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=IWYFU805mOewSezodMC+w1Bl5RFlicIcEaUfLdEfLaA=; b=nRMO3zKoejIkSQgtF/3KWG2DJgZsDvJxcnwaxqJzjOO3qAUASPpumKAckQt8FtpAqZ pP9JS7e6pRE5/4G7lrAw9QfrPT+e1hNJpe6YZs9z1ZBfPU5PUV8+2YtCw5lUMPkua2Qx rhBgMhf8/tb5rUe4o+TrsAcGwLwlKQJeN4nE0U4Hox2niBl+PkrRlyWD2owBVroWLa25 m0VzSvqaxbRQM1bJSTTP8SmIHyTPIrDuqTAISZmH0ZPpa0GQSOcEvE5Crc/sPfyO/Z3b E6K/BGmc2Bd4jhiEoppp0f6aEbVt6DVx4U4xNuB4BOh9v/uE3XUjKxwT+HlniDDxwFjO cmyA== 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=IWYFU805mOewSezodMC+w1Bl5RFlicIcEaUfLdEfLaA=; b=Q2GPgE6DwLy8NOwLUUP/SI0EjmJJn47/VeDERXlHjHteyNOiP7qXIcTL9zWUk2aF/z jlKIp0jH7ziSDyEvn91BPtU5OJRQAC6uUK5KnFgNliD7dgJxRbW8vZsHgkHD8niTVeeo oJKIvOxh1VP1MP0AJOqmiv8SBsgdc8l/flMYJqMWcOqZ+cVsc6q0UnQUc/BUuvSVNICI xOKcZh/m3NPRpLO9oal851KlMBmZQiUZ2HPqzIuuqbW2baH9nGeFIaNU7zevMp5SaXPZ sQHTo58h5Dw5e71jmtdbM2rd7ddNI4j2XCUym8SAeGhPEOzPDrmUf/mSQS4Rs9hO+383 kQsA== X-Gm-Message-State: AOAM533yZTBBHoKD0DZ3EDAkYLTOma6WQ/YmO9Da7qU6KdYsTnXcQ1jO dGWMA0j/PwuYlVJ8QX71YfvCnl9pN68ba3c0ExE= X-Google-Smtp-Source: ABdhPJy2bZ39GZ/c/SIc62j5cfF3Xs1vVP5ldjhWQ8tY7jRDslscvliWY7S3LD5IpjnDVwqJZgbOZkJZx5keVGuC0ng= X-Received: by 2002:a92:de4b:: with SMTP id e11mr2631518ilr.123.1613636351956; Thu, 18 Feb 2021 00:19:11 -0800 (PST) MIME-Version: 1.0 References: <6C0CBD9E-BE9B-47F7-8361-25785DCFDC82@mit.edu> In-Reply-To: <6C0CBD9E-BE9B-47F7-8361-25785DCFDC82@mit.edu> From: Fabien Imbault Date: Thu, 18 Feb 2021 09:19:00 +0100 Message-ID: To: Justin Richer Cc: txauth gnap Content-Type: multipart/alternative; boundary="0000000000008e1cc905bb97fd14" Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 08:19:15 -0000 --0000000000008e1cc905bb97fd14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, I agree that defining AS role primarily as a token issuer is a fruitful idea. Solving this problem well would also respond to the challenges discussed previously on the list. Cheers Fabien Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer a = =C3=A9crit : > The last interim call had a lot of discussion on SSI technologies such as > digital wallets, and how those fit with GNAP. I think it=E2=80=99s worth = continuing > that conversation here on the list. There are a few issues in the tracker > that give some background, too: > > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 > > There=E2=80=99s been a lot of interesting work recently in the OpenID Fou= ndation > around using the Self-issued OP (SIOP) functionality to bootstrap an SSI > style login. This makes extensive use of the implicit flow and front > channel messaging, but minimization of the front channel for message > passing is a key design tenet of GNAP (so much so that it=E2=80=99s inclu= ded in our > charter). Instead, GNAP has been built around an idea that everything > starts the same way: with an HTTP request to the AS. > > The idea of an on-device AS has been brought up a lot, and we need to > consider if and how we want to deal with these kinds of use cases. The mo= st > obvious way to address these would be to do some kind of clever off-HTTP > hack like SIOP, but keep in mind that even SIOP generally starts off with > an HTTP-based discovery call by the RP to make things work. > > My personal stance is that to do this, we need to re-evaluate our > assumptions about exactly what an AS does and what it needs to do those > things. In OAuth 2, it=E2=80=99s assumed that the AS is the device that= =E2=80=99s > authenticating the user, collecting consent, managing the client=E2=80=99= s > registration, and creating an access token based on whatever set of right= s > that are associated with all of those things. In UMA, this is turned arou= nd > a bit by letting the RO present a bunch of nebulous =E2=80=9Cclaims=E2=80= =9D interactively, > but still at the AS. > > With both of these, a key aspect remains: the AS needs to gather necessar= y > information, and issue the access token (or identifiers/assertions). > Because of how the protocol works, the client software now has a better > opportunity to present information to the AS, either directly in the > request or by introducing the AS to another software component during the > =E2=80=9Cinteraction=E2=80=9D phase. So, what if we think of the AS prima= rily as a =E2=80=9Ctoken > issuer=E2=80=9D? > > For example, if the client can present a verifiable credential (VC) that > represents the end user, the AS can validate that VC and make an access > token on behalf of that user, without having the user log in or interact > with the AS at all. This VC can contain whatever access rights the token > needs to represent, and the AS can translate that into an artifact that t= he > downstream RS=E2=80=99s can interpret, without having to see the original= VC or the > user at all. The AS is still HTTP based, but all the essential security a= nd > rights elements are provided by the wallet. In this way, we can expand on > the privacy-preserving aspects of OAuth and bridge the worlds of SSI and > web APIs without violating the basic nature of either. > > Coming from the OAuth world, it feels weird to issue tokens like this, bu= t > there=E2=80=99s precedent for this kind of thing. Today, a there are a nu= mber of > service-based OAuth AS's that are told what claims need to get put into t= he > access token by some trusted component. All of this happens outside the > OAuth protocol. In GNAP, I think it makes sense to account for this kind = of > thing in how we define the protocol. That isn=E2=80=99t to say all of the= se pieces > need to be defined in the core, but the base protocol ought to be able to > handle being extended in this direction as needed. > > I=E2=80=99m really interested to hear other people=E2=80=99s thoughts on = how this could > come together. > > =E2=80=94 Justin > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000008e1cc905bb97fd14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Justin,

    I= agree that defining AS role primarily as a token issuer is a fruitful idea= . Solving this problem well would also respond to the challenges discussed = previously on the list.=C2=A0

    Cheers
    Fabien=C2=A0


    Le mer. 17= f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:
    The last interim call had a lot of discussion on SSI technologies s= uch as digital wallets, and how those fit with GNAP. I think it=E2=80=99s w= orth continuing that conversation here on the list. There are a few issues = in the tracker that give some background, too:


    There=E2=80=99s been a = lot of interesting work recently in the OpenID Foundation around using the = Self-issued OP (SIOP) functionality to bootstrap an SSI style login. This m= akes extensive use of the implicit flow and front channel messaging, but mi= nimization of the front channel for message passing is a key design tenet o= f GNAP (so much so that it=E2=80=99s included in our charter). Instead, GNA= P has been built around an idea that everything starts the same way: with a= n HTTP request to the AS.=C2=A0

    The idea of an on-= device AS has been brought up a lot, and we need to consider if and how we = want to deal with these kinds of use cases. The most obvious way to address= these would be to do some kind of clever off-HTTP hack like SIOP, but keep= in mind that even SIOP generally starts off with an HTTP-based discovery c= all by the RP to make things work.

    My personal sta= nce is that to do this, we need to re-evaluate our assumptions about exactl= y what an AS does and what it needs to do those things. In OAuth 2, it=E2= =80=99s assumed that the AS is the device that=E2=80=99s authenticating the= user, collecting consent, managing the client=E2=80=99s registration, and = creating an access token based on whatever set of rights that are associate= d with all of those things. In UMA, this is turned around a bit by letting = the RO present a bunch of nebulous =E2=80=9Cclaims=E2=80=9D interactively, = but still at the AS.=C2=A0

    With both of these, a k= ey aspect remains: the AS needs to gather necessary information, and issue = the access token (or identifiers/assertions). Because of how the protocol w= orks, the client software now has a better opportunity to present informati= on to the AS, either directly in the request or by introducing the AS to an= other software component during the =E2=80=9Cinteraction=E2=80=9D phase. So= , what if we think of the AS primarily as a =E2=80=9Ctoken issuer=E2=80=9D?= =C2=A0

    For example, if the client can present a ve= rifiable credential (VC) that represents the end user, the AS can validate = that VC and make an access token on behalf of that user, without having the= user log in or interact with the AS at all. This VC can contain whatever a= ccess rights the token needs to represent, and the AS can translate that in= to an artifact that the downstream RS=E2=80=99s can interpret, without havi= ng to see the original VC or the user at all. The AS is still HTTP based, b= ut all the essential security and rights elements are provided by the walle= t. In this way, we can expand on the privacy-preserving aspects of OAuth an= d bridge the worlds of SSI and web APIs without violating the basic nature = of either.

    Coming from the OAuth world, it feels w= eird to issue tokens like this, but there=E2=80=99s precedent for this kind= of thing. Today, a there are a number of service-based OAuth AS's that= are told what claims need to get put into the access token by some trusted= component. All of this happens outside the OAuth protocol. In GNAP, I thin= k it makes sense to account for this kind of thing in how we define the pro= tocol. That isn=E2=80=99t to say all of these pieces need to be defined in = the core, but the base protocol ought to be able to handle being extended i= n this direction as needed.

    I=E2=80=99m really int= erested to hear other people=E2=80=99s thoughts on how this could come toge= ther.

    =C2=A0=E2=80=94 Justin
    -- <= br> TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --0000000000008e1cc905bb97fd14-- From nobody Thu Feb 18 04:26:35 2021 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 CCF613A1186 for ; Thu, 18 Feb 2021 04:26:33 -0800 (PST) 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 oLxCWQfDigFK for ; Thu, 18 Feb 2021 04:26:32 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 3A8993A1172 for ; Thu, 18 Feb 2021 04:26:32 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id o15so1281470ilt.6 for ; Thu, 18 Feb 2021 04:26:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=osOfPdUCKNrbGvcSOciNEvHfpo/nBtmwKhmgfrI/8qU=; b=AzCBN0S5xUICf7q1ArVYI1lk6XQGYStALy4JviFQq4hv2WWqJO0sBJN/9wu9PNpJly pV0iMlPJeWNCvMdy/93VOlQubH2JfiTswthREDZ9ePn8LYEF2XAEyWB7esTlYSDuuevO 1XF6VDaiYr/6xsoxW/FKL4Pw1BhE46S/DSStLkXRx50WHP8RwSKCkZPH59OE9bYsYqFq mxkG60KAwjKNPB2l0IRNKCiEfqgyOjj4u8odFypZLsrdnvmhdPoDLWPVm5Gd604y3uXw GdCVodZJ7QKt81hIVwyb1Ou4Q9KtoO4L6/PQTamJSkeQL5KEBAFOap2KrjhJzCeqEMK3 jOKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=osOfPdUCKNrbGvcSOciNEvHfpo/nBtmwKhmgfrI/8qU=; b=fOSVmn/pzc65MATYAvpH/Zn5iIeODC2Vf4U3goGvbSJ6TDqaxTWRYl3+adcsZG5D6/ p9CESoW5qMh8AWLDM/0kYiy4dR3ID5dxZJFgvUcu3wCa9ohd7SLpgLNePcUZH4A/rp4b 2RRZxYXFxqgAu68oiF/lH6Qk0j4d9eF0Yz25pBSczpPFxdxGjNBwM/mRISszPatRJkp8 gxpqabEt2QypyFteE7bBxMtdAqLYdAxuNqmVYklXTXGppHlZX/FcJyv+c5ECnNls7dXd J4TDDhG7CFxyJz+RG2MKjIQCH22tDQdIDkOY61L6wx99vD/x8GnhYDJb1vzskUyy+Dy0 Cuzw== X-Gm-Message-State: AOAM532z7A6WC75PaziSAaf4ktkwNUPmHjry/WLZcJRn7RWFUplgkB/j kbeZBPOCqSQ84ZoQ+16wxv6TKXNDIeQ9sa5YCF8D01P2WmdkLw== X-Google-Smtp-Source: ABdhPJxcHNnAU/kwXfJUXT0MzK1ESWZ5mk1W8Iuoji3rKbD7KSMg4Ojyfe0UjolrHtyiCNXPI8I3Vy9KlAsFoSvYjZE= X-Received: by 2002:a05:6e02:1cac:: with SMTP id x12mr3606604ill.188.1613651191351; Thu, 18 Feb 2021 04:26:31 -0800 (PST) MIME-Version: 1.0 From: Fabien Imbault Date: Thu, 18 Feb 2021 13:26:20 +0100 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000000d50f605bb9b72fb" Archived-At: Subject: [GNAP] Editorial team update - prepare to publish draft 04 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 12:26:34 -0000 --0000000000000d50f605bb9b72fb Content-Type: text/plain; charset="UTF-8" Hi everyone, Yesterday the editorial made its regular meeting to follow up on issues and PRs. *Imminent merge (to publish v04 for IETF110) * Aaron's PR #164 (grouping interaction modes) has been put in pending merge state. See https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/164 Since this issue has been extensively discussed in the 2 last interim meetings and all comments included, the editors would like to officially merge it before the cutoff publication date of IETF110. *Please submit any comment on PR#164 before sunday evening, so that we can generate a draft version 04 for IETF110. * Pending merge: PR#183 (Requirements for the location of grant_request_endpoint) is now pending merge. Please submit your comments in the next week, before this gets merged. Merged issues: a) editorial merges have been included for #177 / #179 / #181 / #182 b) standard merge has been done for #170, formally closing issues #98 and #99. The document history log has been merged accordingly. As always, the most recent version from merged issues is available from https://gnap-core-protocol-editors-draft.netlify.app/draft-ietf-gnap-core-protocol.html (and as explained above, the only additional change for draft 04 will be PR#164). Thanks. The GNAP editorial team --0000000000000d50f605bb9b72fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi everyone,=C2=A0

    Yesterday the ed= itorial made its regular meeting to follow up on issues and PRs.
    =
    Imminent merge (to publish v04 for IETF110)=C2=A0
    Aaron's PR #164 (grouping interaction modes) has been put in pen= ding merge state.=C2=A0
    Since this issue has been exten= sively discussed in the 2 last interim meetings and all comments included, = the editors would like to officially merge it before the cutoff publication= date of IETF110.=C2=A0
    Please submit any comment on PR#164 be= fore sunday evening, so that we can generate a draft version 04 for IETF110= .=C2=A0

    Pending merge: PR#183 (Requirements fo= r the location of grant_request_endpoint) is now pending merge. Please subm= it your comments in the next week, before this gets merged.=C2=A0

    Merged issues:=C2=A0
    a) editorial merges have bee= n included for #177 / #179 / #181 / #182
    b) standard merge has be= en done for #170, formally closing issues #98 and #99. The document history= log has been merged accordingly.=C2=A0

    As always,= the most recent version from merged issues is available from=C2=A0https://gnap-core-protocol-editors-draft.netlify.app/draf= t-ietf-gnap-core-protocol.html (and as explained above, the only additi= onal change for draft 04 will be PR#164).=C2=A0

    Th= anks.
    The GNAP editorial team


    =
    --0000000000000d50f605bb9b72fb-- From nobody Thu Feb 18 17:00:37 2021 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 09CE43A0935 for ; Thu, 18 Feb 2021 17:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=mattr-global.20150623.gappssmtp.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 1nCbHnCidiRQ for ; Thu, 18 Feb 2021 17:00:33 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 B6A7F3A0E44 for ; Thu, 18 Feb 2021 16:59:45 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id z190so4113467qka.9 for ; Thu, 18 Feb 2021 16:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattr-global.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wnmumsZEUn1ZSU5QKmGzn39uKQFm/0kRR0dKj6+ZNhI=; b=oLxQYUeZa4smnpXE8GsD/4W5jHumgn/sXoTHqFCKcLcUf/rfAN2L6Uov95M7lnd6pS ne69XgVKGTjbdHeLgd6gPOp6EGs77VEdHJZ8HcGRGMRhdz45IhNSPI+5rhFvfBVsEpR9 75sjF+nU9pwsNLR5KYaPl326KK9Htk5+iVUaZZBTty6SYoFJ9lAqE0QWecvEw8PgHLWD osyg0xAr+jtKTK2SuYXcz7q7qS584eu+CahedzzPSSHcYzQS4FqGTRa+D5a6W99Oj9kz jvQ01RZIGGcwre80619dVzgGHL33M7u7SFyjVPo2NUmg6luHJ6sdzuFDKnvygdTmLCnn onvg== 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=wnmumsZEUn1ZSU5QKmGzn39uKQFm/0kRR0dKj6+ZNhI=; b=pWCi0hgpED4mjp/gFJknZSlT4YryNoUkHsvzPisroFxpdwCz2UzR4lUn7hBzOEk2Uf kqKSkrrHizbSRYZm9EIAepCCIfOYbJQGoo46V5379qDcNuJ+ESd0CwkzSK7RWMihymRT faXsR4aN2W1zTk29+5/V7uunjValKuVga+Z+YDO3LFTe90h0WPgDD8lccMv4h+S9rAp8 ZYuUYfitSP0bBHR/u52bYu0rgo1HZdO0tQ90Enp448B5mWJ8EHHXKpRm/EKJbOTRbMAD 0JrI3h4MhN1XHsvXBIwMeiottP/idCebTNyQAdT7rk91/3DXWFB41unfEstnXnXWAh7J Gq8Q== X-Gm-Message-State: AOAM5331yjywQmnL6aoHSiDcePQr8sfF5qt7yQp+ZP6aj8vhwHgW6OMc hC+iKY54e0ihUJEHT4jdNChOiRgHKUO7cgxP/fTcI1wcC69yVG0sp0HAWtH7LQ9mNL6b3Yq/+P9 7/ab2iZrCVZyTM8ddYg== X-Google-Smtp-Source: ABdhPJxAFGdKRGnY5O/afXsKyv0JrrGNsFOc0ElRZBt95qP4h/K44BU/uqnnmpCGu9n1llK6dSpQafmRj1Q5wJ0PWwo= X-Received: by 2002:a37:6542:: with SMTP id z63mr7097474qkb.346.1613696384480; Thu, 18 Feb 2021 16:59:44 -0800 (PST) MIME-Version: 1.0 References: <6C0CBD9E-BE9B-47F7-8361-25785DCFDC82@mit.edu> In-Reply-To: From: Tobias Looker Date: Fri, 19 Feb 2021 13:59:33 +1300 Message-ID: To: Fabien Imbault Cc: Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="000000000000c5c79305bba5f7a2" Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 01:00:36 -0000 --000000000000c5c79305bba5f7a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin, I think this is a great and timely conversation to be having given the current interest around SSI and efforts like SIOP, I have been doing quite a bit of work in this space as of recent, so thought I'd add a few of the observations that I've made. In my opinion SIOP was really a bucket for solving quite a few different problems, not just one. In particular I think its intent was to solve 3 major ones: 1. Enabling portable identities 2. Solving the NASCAR problem 3. Exploring different deployment models for the provider To drill down briefly on these, note much of my terminology is OpenID based due to SIOPs origin *Enabling portable identities *- In general today in the case of OpenID, the end-users identity as understood by a relying party is scoped within the domain of the provider. Which means if that provider goes out of business or for whatever reason decides to no longer offer the same identity services to the End-User, their identity is essentially gone. Whilst there has been some interesting related work from groups like MODRNA on solutions to combat this like 'Account Porting', they often assume the old provider remains online and willing to facilitate in the account porting process so that the End-User can migrate to a new provider. SIOP actually elected to do something different here by using cryptography, instead of the End-User identifier being something like a GUID asserted within the domain of the provider, SIOP defined this instead as a public key fingerprint associated to a private key that's assumed to be under the control of the user. In doing so the identity itself becomes portable between providers by transferring the associated private key. Now this approach does have drawbacks and arguably encourages what many would refer to as bad cryptographic practise by not allowing any way to do key rotation, however the idea was there. *How GNAP can solve for this?* By having flexibility around how the resource owner / End-User is referred to by the Authorization server (e.g allow the identifier to be something like a public key or a resolvable identifier to public keys such as a DID) *Solving the NASCAR problem *- One of those enduring problems in identity systems, which I think is really about the three way negotiation going on between the RP, the End-User and the Provider. SIOP's solution pushed for most of the power in this decision making process to lie with the End-User, letting them decide who they want as their provider rather than RP's providing an enumeration of who they support via provider icons on their login page and End-Users having to select from those options. It accomplished this via using a custom URL scheme of `openid://` where the End-User would register their chosen provider as a protocol handler for the `openid://` scheme. However, again as a solution it's not without it's challenges, notably; only a single registration at a time can be supported, the actual identity of the provider remains blind to the RP until after the request is sent and it requires registration or some form of default handling (e.g when there is no provider registered). *How GNAP can solve for this?* I actually don't think this is core to GNAP, there may be some considerations around discovery that are worth paying attention to but not much in the core protocol design. *Exploring different deployment models for the provider* - This is the most frequently talked about aspect of SIOP and perhaps the most interesting to GNAP. I like to think about the scope of this issue as designing to allow for either a partially or fully distributed/decentralized provider, rather than a centralized one (e.g an HTTP based AuthZ server). As you noted this does come with its challenges many of which are technical in nature, i.e how to appropriately address a decentralized provider and what protocols are used to communicate with the provider. *How GNAP can solve for this?* I think that's what much of the discussion on this thread will be about and whether there is a hybrid model where some responsibility is still centrally administered like token issuance, while allowing other aspects to occur in a more distributed manner. Ideally though I'd like to see consideration for a completely distributed model too= . Thanks, [image: Mattr website] *Tobias Looker* Mattr +64 (0) 27 378 0461 tobias.looker@mattr.global [image: Mattr website] [image: Mattr on LinkedIn] [image: Mattr on Twitter] [image: Mattr on Github] This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault wrote: > Hi Justin, > > I agree that defining AS role primarily as a token issuer is a fruitful > idea. Solving this problem well would also respond to the challenges > discussed previously on the list. > > Cheers > Fabien > > > Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer = a =C3=A9crit : > >> The last interim call had a lot of discussion on SSI technologies such a= s >> digital wallets, and how those fit with GNAP. I think it=E2=80=99s worth= continuing >> that conversation here on the list. There are a few issues in the tracke= r >> that give some background, too: >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 >> >> There=E2=80=99s been a lot of interesting work recently in the OpenID Fo= undation >> around using the Self-issued OP (SIOP) functionality to bootstrap an SSI >> style login. This makes extensive use of the implicit flow and front >> channel messaging, but minimization of the front channel for message >> passing is a key design tenet of GNAP (so much so that it=E2=80=99s incl= uded in our >> charter). Instead, GNAP has been built around an idea that everything >> starts the same way: with an HTTP request to the AS. >> >> The idea of an on-device AS has been brought up a lot, and we need to >> consider if and how we want to deal with these kinds of use cases. The m= ost >> obvious way to address these would be to do some kind of clever off-HTTP >> hack like SIOP, but keep in mind that even SIOP generally starts off wit= h >> an HTTP-based discovery call by the RP to make things work. >> >> My personal stance is that to do this, we need to re-evaluate our >> assumptions about exactly what an AS does and what it needs to do those >> things. In OAuth 2, it=E2=80=99s assumed that the AS is the device that= =E2=80=99s >> authenticating the user, collecting consent, managing the client=E2=80= =99s >> registration, and creating an access token based on whatever set of righ= ts >> that are associated with all of those things. In UMA, this is turned aro= und >> a bit by letting the RO present a bunch of nebulous =E2=80=9Cclaims=E2= =80=9D interactively, >> but still at the AS. >> >> With both of these, a key aspect remains: the AS needs to gather >> necessary information, and issue the access token (or >> identifiers/assertions). Because of how the protocol works, the client >> software now has a better opportunity to present information to the AS, >> either directly in the request or by introducing the AS to another softw= are >> component during the =E2=80=9Cinteraction=E2=80=9D phase. So, what if we= think of the AS >> primarily as a =E2=80=9Ctoken issuer=E2=80=9D? >> >> For example, if the client can present a verifiable credential (VC) that >> represents the end user, the AS can validate that VC and make an access >> token on behalf of that user, without having the user log in or interact >> with the AS at all. This VC can contain whatever access rights the token >> needs to represent, and the AS can translate that into an artifact that = the >> downstream RS=E2=80=99s can interpret, without having to see the origina= l VC or the >> user at all. The AS is still HTTP based, but all the essential security = and >> rights elements are provided by the wallet. In this way, we can expand o= n >> the privacy-preserving aspects of OAuth and bridge the worlds of SSI and >> web APIs without violating the basic nature of either. >> >> Coming from the OAuth world, it feels weird to issue tokens like this, >> but there=E2=80=99s precedent for this kind of thing. Today, a there are= a number >> of service-based OAuth AS's that are told what claims need to get put in= to >> the access token by some trusted component. All of this happens outside = the >> OAuth protocol. In GNAP, I think it makes sense to account for this kind= of >> thing in how we define the protocol. That isn=E2=80=99t to say all of th= ese pieces >> need to be defined in the core, but the base protocol ought to be able t= o >> handle being extended in this direction as needed. >> >> I=E2=80=99m really interested to hear other people=E2=80=99s thoughts on= how this could >> come together. >> >> =E2=80=94 Justin >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 This communication, including any attachments, is confidential. If you are= =20 not the intended recipient, you should not read it - please contact me=20 immediately, destroy it, and do not copy or use any part of this=20 communication or disclose anything about it. Thank you. Please note that=20 this communication does not designate an information system for the=20 purposes of the Electronic Transactions Act 2002. --000000000000c5c79305bba5f7a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Justin,

    I think this is a great and timely conversa= tion to be having given the current interest around SSI and efforts like SI= OP, I have been doing quite a bit of work in this space as of recent, so th= ought I'd add a few of the observations that I've made.

    In m= y opinion SIOP was really a bucket for solving quite a few different proble= ms, not just one. In particular I think its intent was to solve 3 major one= s:

    1. Enabling portable identities
    2. Solving the NASCAR problem<= br>3. Exploring different deployment models for the provider

    To dril= l down briefly on these, note much of my terminology is OpenID based due to= SIOPs origin=C2=A0

    Enabling portable identities - In general= today in the case of OpenID, the end-users identity as understood by a rel= ying party is scoped within the domain of the provider. Which means if that= provider goes out of business or for whatever reason decides to no longer = offer the same identity services to the End-User, their identity is essenti= ally gone. Whilst there has been some interesting related work from groups = like MODRNA on solutions to combat this like 'Account Porting', the= y often assume the old provider remains online and willing to facilitate in= the account porting process so that the End-User can migrate to a new prov= ider. SIOP actually elected to do something different here by using cryptog= raphy, instead of the End-User identifier being something like a GUID asser= ted within the domain of the provider, SIOP defined this instead as a publi= c key fingerprint associated to a private key that's assumed to be unde= r the control of the user. In doing so the identity itself becomes portable= between providers by transferring the associated private key. Now this app= roach does have drawbacks and arguably encourages what many would refer to = as bad cryptographic practise by not allowing any way to do key rotation, h= owever the idea was there.=C2=A0

    How GNAP can solve f= or this? By having flexibility around how the resource owner / End-User= is referred to by the Authorization server (e.g allow the identifier to be= something like a public key or a resolvable identifier to public keys such= as a DID)

    Solving the NASCAR problem - One of those enduring= problems in identity systems, which I think is really about the three way = negotiation going on between the RP, the End-User and the Provider. SIOP= 9;s solution pushed for most of the power in this decision making process t= o lie with the End-User, letting them decide who they want as their provide= r rather than RP's providing an enumeration of who they support via pro= vider icons on their login page and End-Users having to select from those o= ptions. It accomplished this via using a custom URL scheme of `openid://` w= here the End-User would register their chosen provider as a protocol handle= r for the `openid://` scheme. However, again as a solution it's not wit= hout it's challenges, notably; only a single registration at a time can= be supported, the actual identity of the provider remains blind to the RP = until after the request is sent and it requires registration or some form o= f default handling (e.g when there is no provider registered).

    Ho= w GNAP can solve for this? I actually don't think this is core to G= NAP, there may be some considerations around discovery that are worth payin= g attention to but not much in the core protocol design.

    Explorin= g different deployment models for the provider - This is the most frequ= ently talked about aspect of SIOP and perhaps the most interesting to GNAP.= I like to think about the scope of this issue as designing to allow for ei= ther a partially or fully distributed/decentralized provider, rather than a= centralized one (e.g an HTTP=C2=A0based AuthZ server). As you noted this d= oes come with its challenges many of which are technical in nature, i.e how= to appropriately address a decentralized provider and what protocols are u= sed to communicate with the provider.

    How GNAP can solve for thi= s? I think that's=C2=A0what much of the discussion on this thread w= ill be about and whether there is a hybrid model where some responsibility = is still centrally administered like token issuance, while allowing other a= spects to occur in a more distributed manner. Ideally though I'd like t= o see consideration for a completely distributed model too.
    =

    Thanks,
    <= img src=3D"https://mattr.global/assets/images/MattrLogo.png" alt=3D"Mattr w= ebsite" width=3D"125" height=3D"125" style=3D"height:auto">=C2=A0Tobias Looker
    =
    Mattr
    +64 (0) 27 378 0461
    tobias.l= ooker@mattr.global
    3D"Mattr3D"Mattr3D"Mattr<= a href=3D"https://github.com/mattrglobal" style=3D"border:none;color:rgb(51= ,49,50);margin-right:12px" target=3D"_blank">3D"Mattr

    This communication, including any attachments, is confi= dential. If you are not the intended recipient, you should not read it - pl= ease contact me immediately, destroy it, and do not copy or use any part of= this communication or disclose anything about it. Thank you. Please note t= hat this communication does not designate an information system for the pur= poses of the Electronic Transactions Act 2002.


    On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    <= /div>
    Hi= Justin,

    I agree that defining= AS role primarily as a token issuer is a fruitful idea. Solving this probl= em well would also respond to the challenges discussed previously on the li= st.=C2=A0

    Cheers
    Fabien=C2=A0


    Le mer. 17 f=C3=A9vr. 2021 =C3= =A0 23:27, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:
    https://github.com/ietf-wg-gnap/gnap-core-protocol/iss= ues/175

    There=E2=80=99s been a lot of int= eresting work recently in the OpenID Foundation around using the Self-issue= d OP (SIOP) functionality to bootstrap an SSI style login. This makes exten= sive use of the implicit flow and front channel messaging, but minimization= of the front channel for message passing is a key design tenet of GNAP (so= much so that it=E2=80=99s included in our charter). Instead, GNAP has been= built around an idea that everything starts the same way: with an HTTP req= uest to the AS.=C2=A0

    The idea of an on-device AS = has been brought up a lot, and we need to consider if and how we want to de= al with these kinds of use cases. The most obvious way to address these wou= ld be to do some kind of clever off-HTTP hack like SIOP, but keep in mind t= hat even SIOP generally starts off with an HTTP-based discovery call by the= RP to make things work.

    My personal stance is tha= t to do this, we need to re-evaluate our assumptions about exactly what an = AS does and what it needs to do those things. In OAuth 2, it=E2=80=99s assu= med that the AS is the device that=E2=80=99s authenticating the user, colle= cting consent, managing the client=E2=80=99s registration, and creating an = access token based on whatever set of rights that are associated with all o= f those things. In UMA, this is turned around a bit by letting the RO prese= nt a bunch of nebulous =E2=80=9Cclaims=E2=80=9D interactively, but still at= the AS.=C2=A0

    With both of these, a key aspect re= mains: the AS needs to gather necessary information, and issue the access t= oken (or identifiers/assertions). Because of how the protocol works, the cl= ient software now has a better opportunity to present information to the AS= , either directly in the request or by introducing the AS to another softwa= re component during the =E2=80=9Cinteraction=E2=80=9D phase. So, what if we= think of the AS primarily as a =E2=80=9Ctoken issuer=E2=80=9D?=C2=A0
    =

    For example, if the client can present a verifiable cre= dential (VC) that represents the end user, the AS can validate that VC and = make an access token on behalf of that user, without having the user log in= or interact with the AS at all. This VC can contain whatever access rights= the token needs to represent, and the AS can translate that into an artifa= ct that the downstream RS=E2=80=99s can interpret, without having to see th= e original VC or the user at all. The AS is still HTTP based, but all the e= ssential security and rights elements are provided by the wallet. In this w= ay, we can expand on the privacy-preserving aspects of OAuth and bridge the= worlds of SSI and web APIs without violating the basic nature of either.

    Coming from the OAuth world, it feels weird to issu= e tokens like this, but there=E2=80=99s precedent for this kind of thing. T= oday, a there are a number of service-based OAuth AS's that are told wh= at claims need to get put into the access token by some trusted component. = All of this happens outside the OAuth protocol. In GNAP, I think it makes s= ense to account for this kind of thing in how we define the protocol. That = isn=E2=80=99t to say all of these pieces need to be defined in the core, bu= t the base protocol ought to be able to handle being extended in this direc= tion as needed.

    I=E2=80=99m really interested to h= ear other people=E2=80=99s thoughts on how this could come together.
    <= div>
    =C2=A0=E2=80=94 Justin
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
    --000000000000c5c79305bba5f7a2-- From nobody Fri Feb 19 11:30:15 2021 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 81ABA3A13B4 for ; Fri, 19 Feb 2021 11:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 sJahikRNVqJf for ; Fri, 19 Feb 2021 11:30:09 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6973A13B3 for ; Fri, 19 Feb 2021 11:30:08 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11JJU5kw000835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Feb 2021 14:30:06 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FF56E564-E71F-41F2-8550-56F0C9060463" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 19 Feb 2021 14:30:05 -0500 In-Reply-To: Cc: Fabien Imbault , txauth gnap To: Tobias Looker References: <6C0CBD9E-BE9B-47F7-8361-25785DCFDC82@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 19:30:14 -0000 --Apple-Mail=_FF56E564-E71F-41F2-8550-56F0C9060463 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tobias, thanks for the great observations. Some reactions inline below. > On Feb 18, 2021, at 7:59 PM, Tobias Looker = wrote: >=20 > Justin, >=20 > I think this is a great and timely conversation to be having given the = current interest around SSI and efforts like SIOP, I have been doing = quite a bit of work in this space as of recent, so thought I'd add a few = of the observations that I've made. >=20 > In my opinion SIOP was really a bucket for solving quite a few = different problems, not just one. In particular I think its intent was = to solve 3 major ones: >=20 > 1. Enabling portable identities > 2. Solving the NASCAR problem > 3. Exploring different deployment models for the provider >=20 > To drill down briefly on these, note much of my terminology is OpenID = based due to SIOPs origin=20 >=20 > Enabling portable identities - In general today in the case of OpenID, = the end-users identity as understood by a relying party is scoped within = the domain of the provider. Which means if that provider goes out of = business or for whatever reason decides to no longer offer the same = identity services to the End-User, their identity is essentially gone. = Whilst there has been some interesting related work from groups like = MODRNA on solutions to combat this like 'Account Porting', they often = assume the old provider remains online and willing to facilitate in the = account porting process so that the End-User can migrate to a new = provider. SIOP actually elected to do something different here by using = cryptography, instead of the End-User identifier being something like a = GUID asserted within the domain of the provider, SIOP defined this = instead as a public key fingerprint associated to a private key that's = assumed to be under the control of the user. In doing so the identity = itself becomes portable between providers by transferring the associated = private key. Now this approach does have drawbacks and arguably = encourages what many would refer to as bad cryptographic practise by not = allowing any way to do key rotation, however the idea was there.=20 >=20 > How GNAP can solve for this? By having flexibility around how the = resource owner / End-User is referred to by the Authorization server = (e.g allow the identifier to be something like a public key or a = resolvable identifier to public keys such as a DID) I personally think that GNAP should be a flexible :carrier: of = identifiers and other bits of identity information. This is the main = reason we went with the Subject Identifiers draft from SECEVENT: it=E2=80=99= s set up to talk about a variety of different kinds of identifiers, all = of them asserted in the context of the AS. If there=E2=80=99s a = definition for a DID URL or a JWK in the sub_ids object structure, GNAP = would be able to just use it directly alongside every other format. I = haven=E2=80=99t seen those proposed yet, but it would be easy to do and, = in my mind, would be a better solution than the portable identifiers = proposal that was recently brought up in the FAPI working group in OIDF. = (A side note, but the main problem I have here is that it=E2=80=99s = pasting semantics and formats onto a field where none existed before, = and that=E2=80=99s rife for problems. Better to have a structure that = takes that into account from the start, in my view.) >=20 > Solving the NASCAR problem - One of those enduring problems in = identity systems, which I think is really about the three way = negotiation going on between the RP, the End-User and the Provider. = SIOP's solution pushed for most of the power in this decision making = process to lie with the End-User, letting them decide who they want as = their provider rather than RP's providing an enumeration of who they = support via provider icons on their login page and End-Users having to = select from those options. It accomplished this via using a custom URL = scheme of `openid://` where the End-User would register their chosen = provider as a protocol handler for the `openid://` scheme. However, = again as a solution it's not without it's challenges, notably; only a = single registration at a time can be supported, the actual identity of = the provider remains blind to the RP until after the request is sent and = it requires registration or some form of default handling (e.g when = there is no provider registered). >=20 > How GNAP can solve for this? I actually don't think this is core to = GNAP, there may be some considerations around discovery that are worth = paying attention to but not much in the core protocol design. >=20 SIOP doesn=E2=80=99t really solve the NASCAR issue since SIOP, by = design, becomes yet one more login option among many. I think GNAP can = help this by enabling user-directed provider discovery to kick off the = process, but I agree that the core protocol doesn=E2=80=99t really have = much to say here, and shouldn=E2=80=99t. > Exploring different deployment models for the provider - This is the = most frequently talked about aspect of SIOP and perhaps the most = interesting to GNAP. I like to think about the scope of this issue as = designing to allow for either a partially or fully = distributed/decentralized provider, rather than a centralized one (e.g = an HTTP based AuthZ server). As you noted this does come with its = challenges many of which are technical in nature, i.e how to = appropriately address a decentralized provider and what protocols are = used to communicate with the provider.=20 >=20 > How GNAP can solve for this? I think that's what much of the = discussion on this thread will be about and whether there is a hybrid = model where some responsibility is still centrally administered like = token issuance, while allowing other aspects to occur in a more = distributed manner. Ideally though I'd like to see consideration for a = completely distributed model too. I agree that this seems to be the most interesting place for overlap. I = don=E2=80=99t actually think the =E2=80=9Chybrid=E2=80=9D approach = centralizes things. Instead, you can think of the RS as having an = associated AS, and that AS accepting user consent and claims at runtime = from a variety of sources (wallets, VCs, etc.). In this way, we aren=E2=80= =99t talking about a single AS in the world handling all of these = requests, we=E2=80=99re talking about a distributed network of AS=E2=80=99= s associated with an even more widely distributed set of RS=E2=80=99s. = SSI and its associated technologies would help these =E2=80=9Clocal=E2=80=9D= AS=E2=80=99s issue access tokens without the RO needing to have an = account, or even necessarily directly interacting with the AS. There=E2=80= =99s currently a technology gap there, but my thoughts are that this is = where the changes to the interaction modes section can really come to = play.=20 I think the notion of a non-HTTP AS is interesting, but I=E2=80=99m not = sure if that=E2=80=99s something GNAP ought to be solving for. I think = that there=E2=80=99s a deep value in building on top of HTTP for the = core protocol, and not abstracting away concepts from it. Otherwise, you = end up re-inventing layers, and you get something like SOAP all over = again. :) =E2=80=94 Justin >=20 > Thanks, > =09 > Tobias Looker > Mattr > +64 (0) 27 378 0461 > tobias.looker@mattr.global > = = = > This communication, including any attachments, is confidential. If you = are not the intended recipient, you should not read it - please contact = me immediately, destroy it, and do not copy or use any part of this = communication or disclose anything about it. Thank you. Please note that = this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. >=20 >=20 > On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault = > wrote: > Hi Justin, >=20 > I agree that defining AS role primarily as a token issuer is a = fruitful idea. Solving this problem well would also respond to the = challenges discussed previously on the list.=20 >=20 > Cheers > Fabien=20 >=20 >=20 > Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer = > a =C3=A9crit : > The last interim call had a lot of discussion on SSI technologies such = as digital wallets, and how those fit with GNAP. I think it=E2=80=99s = worth continuing that conversation here on the list. There are a few = issues in the tracker that give some background, too: >=20 > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 = >=20 > There=E2=80=99s been a lot of interesting work recently in the OpenID = Foundation around using the Self-issued OP (SIOP) functionality to = bootstrap an SSI style login. This makes extensive use of the implicit = flow and front channel messaging, but minimization of the front channel = for message passing is a key design tenet of GNAP (so much so that = it=E2=80=99s included in our charter). Instead, GNAP has been built = around an idea that everything starts the same way: with an HTTP request = to the AS.=20 >=20 > The idea of an on-device AS has been brought up a lot, and we need to = consider if and how we want to deal with these kinds of use cases. The = most obvious way to address these would be to do some kind of clever = off-HTTP hack like SIOP, but keep in mind that even SIOP generally = starts off with an HTTP-based discovery call by the RP to make things = work. >=20 > My personal stance is that to do this, we need to re-evaluate our = assumptions about exactly what an AS does and what it needs to do those = things. In OAuth 2, it=E2=80=99s assumed that the AS is the device = that=E2=80=99s authenticating the user, collecting consent, managing the = client=E2=80=99s registration, and creating an access token based on = whatever set of rights that are associated with all of those things. In = UMA, this is turned around a bit by letting the RO present a bunch of = nebulous =E2=80=9Cclaims=E2=80=9D interactively, but still at the AS.=20 >=20 > With both of these, a key aspect remains: the AS needs to gather = necessary information, and issue the access token (or = identifiers/assertions). Because of how the protocol works, the client = software now has a better opportunity to present information to the AS, = either directly in the request or by introducing the AS to another = software component during the =E2=80=9Cinteraction=E2=80=9D phase. So, = what if we think of the AS primarily as a =E2=80=9Ctoken issuer=E2=80=9D?=20= >=20 > For example, if the client can present a verifiable credential (VC) = that represents the end user, the AS can validate that VC and make an = access token on behalf of that user, without having the user log in or = interact with the AS at all. This VC can contain whatever access rights = the token needs to represent, and the AS can translate that into an = artifact that the downstream RS=E2=80=99s can interpret, without having = to see the original VC or the user at all. The AS is still HTTP based, = but all the essential security and rights elements are provided by the = wallet. In this way, we can expand on the privacy-preserving aspects of = OAuth and bridge the worlds of SSI and web APIs without violating the = basic nature of either. >=20 > Coming from the OAuth world, it feels weird to issue tokens like this, = but there=E2=80=99s precedent for this kind of thing. Today, a there are = a number of service-based OAuth AS's that are told what claims need to = get put into the access token by some trusted component. All of this = happens outside the OAuth protocol. In GNAP, I think it makes sense to = account for this kind of thing in how we define the protocol. That = isn=E2=80=99t to say all of these pieces need to be defined in the core, = but the base protocol ought to be able to handle being extended in this = direction as needed. >=20 > I=E2=80=99m really interested to hear other people=E2=80=99s thoughts = on how this could come together. >=20 > =E2=80=94 Justin > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 > This communication, including any attachments, is confidential. If you = are not the intended recipient, you should not read it - please contact = me immediately, destroy it, and do not copy or use any part of this = communication or disclose anything about it. Thank you. Please note that = this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. --Apple-Mail=_FF56E564-E71F-41F2-8550-56F0C9060463 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Tobias, thanks for the great observations. Some reactions = inline below.

    On Feb 18, 2021, at 7:59 PM, Tobias Looker = <tobias.looker@mattr.global> wrote:

    Justin,

    I think this is a great and timely conversation to be having = given the current interest around SSI and efforts like SIOP, I have been = doing quite a bit of work in this space as of recent, so thought I'd add = a few of the observations that I've made.

    In = my opinion SIOP was really a bucket for solving quite a few different = problems, not just one. In particular I think its intent was to solve 3 = major ones:

    1. Enabling portable = identities
    2. Solving the NASCAR problem
    3. = Exploring different deployment models for the provider

    To drill down briefly on these, note much of my terminology = is OpenID based due to SIOPs origin 

    Enabling portable identities - In general today in the = case of OpenID, the end-users identity as understood by a relying party = is scoped within the domain of the provider. Which means if that = provider goes out of business or for whatever reason decides to no = longer offer the same identity services to the End-User, their identity = is essentially gone. Whilst there has been some interesting related work = from groups like MODRNA on solutions to combat this like 'Account = Porting', they often assume the old provider remains online and willing = to facilitate in the account porting process so that the End-User can = migrate to a new provider. SIOP actually elected to do something = different here by using cryptography, instead of the End-User identifier = being something like a GUID asserted within the domain of the provider, = SIOP defined this instead as a public key fingerprint associated to a = private key that's assumed to be under the control of the user. In doing = so the identity itself becomes portable between providers by = transferring the associated private key. Now this approach does have = drawbacks and arguably encourages what many would refer to as bad = cryptographic practise by not allowing any way to do key rotation, = however the idea was there. 

    How GNAP can solve for this? By having = flexibility around how the resource owner / End-User is referred to by = the Authorization server (e.g allow the identifier to be something like = a public key or a resolvable identifier to public keys such as a DID)

    I= personally think that GNAP should be a flexible :carrier: of = identifiers and other bits of identity information. This is the main = reason we went with the Subject Identifiers draft from SECEVENT: it=E2=80=99= s set up to talk about a variety of different kinds of identifiers, all = of them asserted in the context of the AS. If there=E2=80=99s a = definition for a DID URL or a JWK in the sub_ids object structure, GNAP = would be able to just use it directly alongside every other format. I = haven=E2=80=99t seen those proposed yet, but it would be easy to do and, = in my mind, would be a better solution than the portable identifiers = proposal that was recently brought up in the FAPI working group in OIDF. = (A side note, but the main problem I have here is that it=E2=80=99s = pasting semantics and formats onto a field where none existed before, = and that=E2=80=99s rife for problems. Better to have a structure that = takes that into account from the start, in my view.)


    Solving the NASCAR problem - One of those enduring = problems in identity systems, which I think is really about the three = way negotiation going on between the RP, the End-User and the Provider. = SIOP's solution pushed for most of the power in this decision making = process to lie with the End-User, letting them decide who they want as = their provider rather than RP's providing an enumeration of who they = support via provider icons on their login page and End-Users having to = select from those options. It accomplished this via using a custom URL = scheme of `openid://` where the = End-User would register their chosen provider as a protocol handler for = the `openid://` scheme. However, = again as a solution it's not without it's challenges, notably; only a = single registration at a time can be supported, the actual identity of = the provider remains blind to the RP until after the request is sent and = it requires registration or some form of default handling (e.g when = there is no provider registered).

    How GNAP can solve for this? I actually don't think this = is core to GNAP, there may be some considerations around discovery that = are worth paying attention to but not much in the core protocol = design.


    SIOP doesn=E2=80=99t really solve the NASCAR issue = since SIOP, by design, becomes yet one more login option among many. I = think GNAP can help this by enabling user-directed provider discovery to = kick off the process, but I agree that the core protocol doesn=E2=80=99t = really have much to say here, and shouldn=E2=80=99t.

    Exploring different = deployment models for the provider - This is the most frequently = talked about aspect of SIOP and perhaps the most interesting to GNAP. I = like to think about the scope of this issue as designing to allow for = either a partially or fully distributed/decentralized provider, rather = than a centralized one (e.g an HTTP based AuthZ server). As you = noted this does come with its challenges many of which are technical in = nature, i.e how to appropriately address a decentralized provider and = what protocols are used to communicate with the provider.

    How GNAP can solve for this? = I think that's what much of the discussion on this thread will be = about and whether there is a hybrid model where some responsibility is = still centrally administered like token issuance, while allowing other = aspects to occur in a more distributed manner. Ideally though I'd like = to see consideration for a completely distributed model = too.

    I = agree that this seems to be the most interesting place for overlap. I = don=E2=80=99t actually think the =E2=80=9Chybrid=E2=80=9D approach = centralizes things. Instead, you can think of the RS as having an = associated AS, and that AS accepting user consent and claims at runtime = from a variety of sources (wallets, VCs, etc.). In this way, we aren=E2=80= =99t talking about a single AS in the world handling all of these = requests, we=E2=80=99re talking about a distributed network of AS=E2=80=99= s associated with an even more widely distributed set of RS=E2=80=99s. = SSI and its associated technologies would help these =E2=80=9Clocal=E2=80=9D= AS=E2=80=99s issue access tokens without the RO needing to have an = account, or even necessarily directly interacting with the AS. There=E2=80= =99s currently a technology gap there, but my thoughts are that this is = where the changes to the interaction modes section can really come to = play. 

    I think the notion of a = non-HTTP AS is interesting, but I=E2=80=99m not sure if that=E2=80=99s = something GNAP ought to be solving for. I think that there=E2=80=99s a = deep value in building on top of HTTP for the core protocol, and not = abstracting away concepts from it. Otherwise, you end up re-inventing = layers, and you get something like SOAP all over again. :)

     =E2=80=94 Justin


    Thanks,
    3D"Mattr 
    Tobias Looker
    Mattr
    +64 = (0) 27 378 0461
    tobias.looker@mattr.global
    3D"Mattr3D"Mattr3D"Mattr3D"Mattr

    This communication, including any attachments, is = confidential. If you are not the intended recipient, you should not read = it - please contact me immediately, destroy it, and do not copy or use = any part of this communication or disclose anything about it. Thank you. = Please note that this communication does not designate an information = system for the purposes of the Electronic Transactions Act = 2002.


    On Thu, Feb 18, 2021 at 9:19 PM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Justin,

    I agree that defining AS role primarily as a token issuer is = a fruitful idea. Solving this problem well would also respond to the = challenges discussed previously on the list. 

    Cheers
    Fabien 


    Le mer. 17 f=C3=A9vr. 2021 =C3=A0 = 23:27, Justin Richer <jricher@mit.edu> a =C3=A9crit :
    The last interim call had a lot of discussion on = SSI technologies such as digital wallets, and how those fit with GNAP. I = think it=E2=80=99s worth continuing that conversation here on the list. = There are a few issues in the tracker that give some background, = too:

    https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175

    There=E2=80=99s been a lot of interesting work recently in = the OpenID Foundation around using the Self-issued OP (SIOP) = functionality to bootstrap an SSI style login. This makes extensive use = of the implicit flow and front channel messaging, but minimization of = the front channel for message passing is a key design tenet of GNAP (so = much so that it=E2=80=99s included in our charter). Instead, GNAP has = been built around an idea that everything starts the same way: with an = HTTP request to the AS. 

    The idea of an on-device AS has been = brought up a lot, and we need to consider if and how we want to deal = with these kinds of use cases. The most obvious way to address these = would be to do some kind of clever off-HTTP hack like SIOP, but keep in = mind that even SIOP generally starts off with an HTTP-based discovery = call by the RP to make things work.

    My personal stance is that to do this, = we need to re-evaluate our assumptions about exactly what an AS does and = what it needs to do those things. In OAuth 2, it=E2=80=99s assumed that = the AS is the device that=E2=80=99s authenticating the user, collecting = consent, managing the client=E2=80=99s registration, and creating an = access token based on whatever set of rights that are associated with = all of those things. In UMA, this is turned around a bit by letting the = RO present a bunch of nebulous =E2=80=9Cclaims=E2=80=9D interactively, = but still at the AS. 

    With both of these, a key aspect remains: the AS needs to = gather necessary information, and issue the access token (or = identifiers/assertions). Because of how the protocol works, the client = software now has a better opportunity to present information to the AS, = either directly in the request or by introducing the AS to another = software component during the =E2=80=9Cinteraction=E2=80=9D phase. So, = what if we think of the AS primarily as a =E2=80=9Ctoken = issuer=E2=80=9D? 

    For example, if the client can present a verifiable = credential (VC) that represents the end user, the AS can validate that = VC and make an access token on behalf of that user, without having the = user log in or interact with the AS at all. This VC can contain whatever = access rights the token needs to represent, and the AS can translate = that into an artifact that the downstream RS=E2=80=99s can interpret, = without having to see the original VC or the user at all. The AS is = still HTTP based, but all the essential security and rights elements are = provided by the wallet. In this way, we can expand on the = privacy-preserving aspects of OAuth and bridge the worlds of SSI and web = APIs without violating the basic nature of either.

    Coming from the OAuth = world, it feels weird to issue tokens like this, but there=E2=80=99s = precedent for this kind of thing. Today, a there are a number of = service-based OAuth AS's that are told what claims need to get put into = the access token by some trusted component. All of this happens outside = the OAuth protocol. In GNAP, I think it makes sense to account for this = kind of thing in how we define the protocol. That isn=E2=80=99t to say = all of these pieces need to be defined in the core, but the base = protocol ought to be able to handle being extended in this direction as = needed.

    I=E2=80=99= m really interested to hear other people=E2=80=99s thoughts on how this = could come together.

     =E2=80=94 Justin
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    =
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    = 

    This communication, including any attachments, is =
confidential. If you are not the intended recipient, you should not read =
it - please contact me immediately, destroy it, and do not copy or use =
any part of this communication or disclose anything about it. Thank you. =
Please note that this communication does not designate an information =
system for the purposes of the Electronic Transactions Act =
2002.

    = --Apple-Mail=_FF56E564-E71F-41F2-8550-56F0C9060463-- From nobody Fri Feb 19 14:50:22 2021 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 A052D3A0C9C for ; Fri, 19 Feb 2021 14:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 rvWbV7_ui-pN for ; Fri, 19 Feb 2021 14:50:17 -0800 (PST) Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) (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 22C703A0C9A for ; Fri, 19 Feb 2021 14:50:17 -0800 (PST) Received: by mail-vs1-f49.google.com with SMTP id y123so3495348vsy.13 for ; Fri, 19 Feb 2021 14:50:17 -0800 (PST) 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=csmy4ZDLgcQoPMmCa6ce02GDoicxMfJP/Nk22cXUaZU=; b=oFN39cXpqqJzoq94gblAFAydl0dE89MsGxkGXUE55ZD7Nma/0bMXoDkeiVTV9vc6mm 8PJr4HIpv8NqvVKBWpvZmEEdBhmna8G32qtWaBHoY+ZmGKzM8SFX9k8Qs5hk2Q8G8adr urHF2q6MfAhvjBg7m6M/6Dz1RIA0Dtu4cyechxBrTvyz8IbXR5wEG8JR+CCtuFehYPYN 5QRSU1Agbe1UbnuC0q9uFytAAVdaijxJ+z0SsMgiSDm2llpQRUF62/gRcJRUgnVyU6p+ 91p9ZpQCTdQKfNPsveF3YRdtyN8bIkKfVVAzpzoCRQg9jPz07/m8V0eGcX+VxXjIAgrz 2J1Q== X-Gm-Message-State: AOAM530eXFQGaC8yszohDpwhtsPYwdisXtu8Qv3IYaht9ie/sKvSByXV p2ZdYGwY/YKOyL84Kc7CVW91td2rnmFJOxG3UMU= X-Google-Smtp-Source: ABdhPJzRx6B5nIyi2DoIXx8hjzKgQfLc//VPkXau8J3k8OtsRw6R4qHAap6zRhgHVFHO4jhfy9JTtkDn3azhCMWZ6W0= X-Received: by 2002:a67:541:: with SMTP id 62mr8553830vsf.39.1613775015752; Fri, 19 Feb 2021 14:50:15 -0800 (PST) MIME-Version: 1.0 References: <6C0CBD9E-BE9B-47F7-8361-25785DCFDC82@mit.edu> In-Reply-To: From: Adrian Gropper Date: Fri, 19 Feb 2021 17:50:04 -0500 Message-ID: To: Justin Richer Cc: Tobias Looker , Fabien Imbault , txauth gnap Content-Type: multipart/alternative; boundary="0000000000008fdb5705bbb84673" Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 22:50:21 -0000 --0000000000008fdb5705bbb84673 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with the first two of Justin's responses but not the last one. It's confusing to think that there are more RS than AS. From a human-centered (and hopefully IETF) perspective, each person might control or specify a different AS for each of their personas or for each child or incompetent delegate of them as guardian. We're familiar with separate gmail addresses for each persona. ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial bitcoin wallet), or brokers (as in data brokers and surveillance capitalism). Any RS that is willing to have a recurring relationship with a persona could accept a GNAP AS endpoint instead of an email address. This is easiest using HTTP, but GNAP need not exclude other RS / AS APIs and transports. Designing around the uncensored specification of one's AS as a human right would greatly simplify many aspects of GNAP adoption. That said, GNAP should not ignore the RS business or jurisdictional reasons to limit the authority of the AS. UMA 2.0 spent years dancing around this issue with ideas like "cascading" AS and various centralized or federated AS concepts. My conclusion is that any RS can always do whatever it wants and there's not much the authorization protocol can help with other than specifying a notification endpoint so that an RS can warn (and seek confirmation) or log various exceptions. This turns out to be, after a year of testimony, the regulation that applies to HIPAA RS APIs in the US. For this reason GNAP might include a notification protocol in the AS specification, or not. I propose that embracing a self-sovereign agent is key to harmonizing the SSI and GNAP standards. Adrian On Fri, Feb 19, 2021 at 2:30 PM Justin Richer wrote: > Tobias, thanks for the great observations. Some reactions inline below. > > On Feb 18, 2021, at 7:59 PM, Tobias Looker > wrote: > > Justin, > > I think this is a great and timely conversation to be having given the > current interest around SSI and efforts like SIOP, I have been doing quit= e > a bit of work in this space as of recent, so thought I'd add a few of the > observations that I've made. > > In my opinion SIOP was really a bucket for solving quite a few different > problems, not just one. In particular I think its intent was to solve 3 > major ones: > > 1. Enabling portable identities > 2. Solving the NASCAR problem > 3. Exploring different deployment models for the provider > > To drill down briefly on these, note much of my terminology is OpenID > based due to SIOPs origin > > *Enabling portable identities *- In general today in the case of OpenID, > the end-users identity as understood by a relying party is scoped within > the domain of the provider. Which means if that provider goes out of > business or for whatever reason decides to no longer offer the same > identity services to the End-User, their identity is essentially gone. > Whilst there has been some interesting related work from groups like MODR= NA > on solutions to combat this like 'Account Porting', they often assume the > old provider remains online and willing to facilitate in the account > porting process so that the End-User can migrate to a new provider. SIOP > actually elected to do something different here by using cryptography, > instead of the End-User identifier being something like a GUID asserted > within the domain of the provider, SIOP defined this instead as a public > key fingerprint associated to a private key that's assumed to be under th= e > control of the user. In doing so the identity itself becomes portable > between providers by transferring the associated private key. Now this > approach does have drawbacks and arguably encourages what many would refe= r > to as bad cryptographic practise by not allowing any way to do key > rotation, however the idea was there. > > *How GNAP can solve for this?* By having flexibility around how the > resource owner / End-User is referred to by the Authorization server (e.g > allow the identifier to be something like a public key or a resolvable > identifier to public keys such as a DID) > > > I personally think that GNAP should be a flexible :carrier: of identifier= s > and other bits of identity information. This is the main reason we went > with the Subject Identifiers draft from SECEVENT: it=E2=80=99s set up to = talk about > a variety of different kinds of identifiers, all of them asserted in the > context of the AS. If there=E2=80=99s a definition for a DID URL or a JWK= in the > sub_ids object structure, GNAP would be able to just use it directly > alongside every other format. I haven=E2=80=99t seen those proposed yet, = but it > would be easy to do and, in my mind, would be a better solution than the > portable identifiers proposal that was recently brought up in the FAPI > working group in OIDF. (A side note, but the main problem I have here is > that it=E2=80=99s pasting semantics and formats onto a field where none e= xisted > before, and that=E2=80=99s rife for problems. Better to have a structure = that takes > that into account from the start, in my view.) > > > *Solving the NASCAR problem *- One of those enduring problems in identity > systems, which I think is really about the three way negotiation going on > between the RP, the End-User and the Provider. SIOP's solution pushed for > most of the power in this decision making process to lie with the End-Use= r, > letting them decide who they want as their provider rather than RP's > providing an enumeration of who they support via provider icons on their > login page and End-Users having to select from those options. It > accomplished this via using a custom URL scheme of `openid://` where the > End-User would register their chosen provider as a protocol handler for t= he > `openid://` scheme. However, again as a solution it's not without it's > challenges, notably; only a single registration at a time can be supporte= d, > the actual identity of the provider remains blind to the RP until after t= he > request is sent and it requires registration or some form of default > handling (e.g when there is no provider registered). > > *How GNAP can solve for this?* I actually don't think this is core to > GNAP, there may be some considerations around discovery that are worth > paying attention to but not much in the core protocol design. > > > SIOP doesn=E2=80=99t really solve the NASCAR issue since SIOP, by design,= becomes > yet one more login option among many. I think GNAP can help this by > enabling user-directed provider discovery to kick off the process, but I > agree that the core protocol doesn=E2=80=99t really have much to say here= , and > shouldn=E2=80=99t. > > *Exploring different deployment models for the provider* - This is the > most frequently talked about aspect of SIOP and perhaps the most > interesting to GNAP. I like to think about the scope of this issue as > designing to allow for either a partially or fully > distributed/decentralized provider, rather than a centralized one (e.g an > HTTP based AuthZ server). As you noted this does come with its challenges > many of which are technical in nature, i.e how to appropriately address a > decentralized provider and what protocols are used to communicate with th= e > provider. > > *How GNAP can solve for this?* I think that's what much of the discussion > on this thread will be about and whether there is a hybrid model where so= me > responsibility is still centrally administered like token issuance, while > allowing other aspects to occur in a more distributed manner. Ideally > though I'd like to see consideration for a completely distributed model t= oo. > > > I agree that this seems to be the most interesting place for overlap. I > don=E2=80=99t actually think the =E2=80=9Chybrid=E2=80=9D approach centra= lizes things. Instead, you > can think of the RS as having an associated AS, and that AS accepting use= r > consent and claims at runtime from a variety of sources (wallets, VCs, > etc.). In this way, we aren=E2=80=99t talking about a single AS in the wo= rld > handling all of these requests, we=E2=80=99re talking about a distributed= network > of AS=E2=80=99s associated with an even more widely distributed set of RS= =E2=80=99s. SSI > and its associated technologies would help these =E2=80=9Clocal=E2=80=9D = AS=E2=80=99s issue access > tokens without the RO needing to have an account, or even necessarily > directly interacting with the AS. There=E2=80=99s currently a technology = gap there, > but my thoughts are that this is where the changes to the interaction mod= es > section can really come to play. > > I think the notion of a non-HTTP AS is interesting, but I=E2=80=99m not s= ure if > that=E2=80=99s something GNAP ought to be solving for. I think that there= =E2=80=99s a deep > value in building on top of HTTP for the core protocol, and not abstracti= ng > away concepts from it. Otherwise, you end up re-inventing layers, and you > get something like SOAP all over again. :) > > =E2=80=94 Justin > > > Thanks, > [image: Mattr website] > *Tobias Looker* > Mattr > +64 (0) 27 378 0461 > tobias.looker@mattr.global > [image: Mattr website] [image: Mattr on LinkedIn] > [image: Mattr on Twitter] > [image: Mattr on Github] > > This communication, including any attachments, is confidential. If you ar= e > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > > On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault > wrote: > >> Hi Justin, >> >> I agree that defining AS role primarily as a token issuer is a fruitful >> idea. Solving this problem well would also respond to the challenges >> discussed previously on the list. >> >> Cheers >> Fabien >> >> >> Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer = a =C3=A9crit : >> >>> The last interim call had a lot of discussion on SSI technologies such >>> as digital wallets, and how those fit with GNAP. I think it=E2=80=99s w= orth >>> continuing that conversation here on the list. There are a few issues i= n >>> the tracker that give some background, too: >>> >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 >>> >>> There=E2=80=99s been a lot of interesting work recently in the OpenID F= oundation >>> around using the Self-issued OP (SIOP) functionality to bootstrap an SS= I >>> style login. This makes extensive use of the implicit flow and front >>> channel messaging, but minimization of the front channel for message >>> passing is a key design tenet of GNAP (so much so that it=E2=80=99s inc= luded in our >>> charter). Instead, GNAP has been built around an idea that everything >>> starts the same way: with an HTTP request to the AS. >>> >>> The idea of an on-device AS has been brought up a lot, and we need to >>> consider if and how we want to deal with these kinds of use cases. The = most >>> obvious way to address these would be to do some kind of clever off-HTT= P >>> hack like SIOP, but keep in mind that even SIOP generally starts off wi= th >>> an HTTP-based discovery call by the RP to make things work. >>> >>> My personal stance is that to do this, we need to re-evaluate our >>> assumptions about exactly what an AS does and what it needs to do those >>> things. In OAuth 2, it=E2=80=99s assumed that the AS is the device that= =E2=80=99s >>> authenticating the user, collecting consent, managing the client=E2=80= =99s >>> registration, and creating an access token based on whatever set of rig= hts >>> that are associated with all of those things. In UMA, this is turned ar= ound >>> a bit by letting the RO present a bunch of nebulous =E2=80=9Cclaims=E2= =80=9D interactively, >>> but still at the AS. >>> >>> With both of these, a key aspect remains: the AS needs to gather >>> necessary information, and issue the access token (or >>> identifiers/assertions). Because of how the protocol works, the client >>> software now has a better opportunity to present information to the AS, >>> either directly in the request or by introducing the AS to another soft= ware >>> component during the =E2=80=9Cinteraction=E2=80=9D phase. So, what if w= e think of the AS >>> primarily as a =E2=80=9Ctoken issuer=E2=80=9D? >>> >>> For example, if the client can present a verifiable credential (VC) tha= t >>> represents the end user, the AS can validate that VC and make an access >>> token on behalf of that user, without having the user log in or interac= t >>> with the AS at all. This VC can contain whatever access rights the toke= n >>> needs to represent, and the AS can translate that into an artifact that= the >>> downstream RS=E2=80=99s can interpret, without having to see the origin= al VC or the >>> user at all. The AS is still HTTP based, but all the essential security= and >>> rights elements are provided by the wallet. In this way, we can expand = on >>> the privacy-preserving aspects of OAuth and bridge the worlds of SSI an= d >>> web APIs without violating the basic nature of either. >>> >>> Coming from the OAuth world, it feels weird to issue tokens like this, >>> but there=E2=80=99s precedent for this kind of thing. Today, a there ar= e a number >>> of service-based OAuth AS's that are told what claims need to get put i= nto >>> the access token by some trusted component. All of this happens outside= the >>> OAuth protocol. In GNAP, I think it makes sense to account for this kin= d of >>> thing in how we define the protocol. That isn=E2=80=99t to say all of t= hese pieces >>> need to be defined in the core, but the base protocol ought to be able = to >>> handle being extended in this direction as needed. >>> >>> I=E2=80=99m really interested to hear other people=E2=80=99s thoughts o= n how this could >>> come together. >>> >>> =E2=80=94 Justin >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > This communication, including any attachments, is confidential. If you ar= e not the intended recipient, you should not read it - please contact me im= mediately, destroy it, and do not copy or use any part of this communicatio= n or disclose anything about it. Thank you. Please note that this communica= tion does not designate an information system for the purposes of the Elect= ronic Transactions Act 2002. > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000008fdb5705bbb84673 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I agree with the=C2=A0first=C2=A0two of Justin's respo= nses but not the last one.

    It's confusing to think t= hat there are more RS than AS. From a human-centered (and hopefully IETF) p= erspective, each person might control or specify a different AS for each of= their personas or for each child or incompetent delegate of them as guardi= an. We're familiar with separate gmail addresses for each persona.

    ASs will be self-sovereign (as in SSI), fiduciary (as = in a custodial bitcoin wallet), or brokers (as in data brokers and surveill= ance capitalism). Any RS that is willing to have a recurring relationship w= ith a persona could accept a GNAP AS endpoint instead of an email address. = This is easiest using HTTP, but GNAP need not exclude other RS / AS APIs an= d transports. Designing around the uncensored specification=C2=A0of one'= ;s AS as a human right would greatly simplify many aspects of GNAP adoption= .

    That said, GNAP should not ignore the RS busines= s or jurisdictional=C2=A0reasons to limit the authority of the AS. UMA 2.0 = spent years dancing around this issue with ideas like "cascading"= AS and various centralized or federated AS concepts. My conclusion is that= any RS can always do whatever it wants and there's not much the author= ization protocol can help with other than specifying a notification endpoin= t so that an RS can warn (and seek confirmation) or log various exceptions.= This turns out to be, after a year of testimony, the regulation that appli= es to HIPAA RS APIs in the US. For this reason GNAP might include a notific= ation protocol in the AS specification, or not.

    I = propose that embracing a self-sovereign agent is key to harmonizing the SSI= and GNAP standards.

    Adrian

    On Fri, Feb 19, 2= 021 at 2:30 PM Justin Richer <jricher= @mit.edu> wrote:
    Tobias, thanks for the great observ= ations. Some reactions inline below.

    =
    On Feb 18, 2021, at 7:59 PM, Tobias Looker <tobias.looker@mattr.global>= wrote:

    Justin,

    I think this is a gre= at and timely conversation to be having given the current interest around S= SI and efforts like SIOP, I have been doing quite a bit of work in this spa= ce as of recent, so thought I'd add a few of the observations that I= 9;ve made.

    In my opinion SIOP was really a bucket for solving quite = a few different problems, not just one. In particular I think its intent wa= s to solve 3 major ones:

    1. Enabling portable identities
    2. Solvi= ng the NASCAR problem
    3. Exploring different deployment models for the p= rovider

    To drill down briefly on these, note much of my terminology = is OpenID based due to SIOPs origin=C2=A0

    Enabling portable ident= ities - In general today in the case of OpenID, the end-users identity = as understood by a relying party is scoped within the domain of the provide= r. Which means if that provider goes out of business or for whatever reason= decides to no longer offer the same identity services to the End-User, the= ir identity is essentially gone. Whilst there has been some interesting rel= ated work from groups like MODRNA on solutions to combat this like 'Acc= ount Porting', they often assume the old provider remains online and wi= lling to facilitate in the account porting process so that the End-User can= migrate to a new provider. SIOP actually elected to do something different= here by using cryptography, instead of the End-User identifier being somet= hing like a GUID asserted within the domain of the provider, SIOP defined t= his instead as a public key fingerprint associated to a private key that= 9;s assumed to be under the control of the user. In doing so the identity i= tself becomes portable between providers by transferring the associated pri= vate key. Now this approach does have drawbacks and arguably encourages wha= t many would refer to as bad cryptographic practise by not allowing any way= to do key rotation, however the idea was there.=C2=A0

    <= b>How GNAP can solve for this? By having flexibility around how the res= ource owner / End-User is referred to by the Authorization server (e.g allo= w the identifier to be something like a public key or a resolvable identifi= er to public keys such as a DID)
    I personally think that GNAP should be a flexible :carrier: of = identifiers and other bits of identity information. This is the main reason= we went with the Subject Identifiers draft from SECEVENT: it=E2=80=99s set= up to talk about a variety of different kinds of identifiers, all of them = asserted in the context of the AS. If there=E2=80=99s a definition for a DI= D URL or a JWK in the sub_ids object structure, GNAP would be able to just = use it directly alongside every other format. I haven=E2=80=99t seen those = proposed yet, but it would be easy to do and, in my mind, would be a better= solution than the portable identifiers proposal that was recently brought = up in the FAPI working group in OIDF. (A side note, but the main problem I = have here is that it=E2=80=99s pasting semantics and formats onto a field w= here none existed before, and that=E2=80=99s rife for problems. Better to h= ave a structure that takes that into account from the start, in my view.)

    Solving= the NASCAR problem - One of those enduring problems in identity system= s, which I think is really about the three way negotiation going on between= the RP, the End-User and the Provider. SIOP's solution pushed for most= of the power in this decision making process to lie with the End-User, let= ting them decide who they want as their provider rather than RP's provi= ding an enumeration of who they support via provider icons on their login p= age and End-Users having to select from those options. It accomplished this= via using a custom URL scheme of `openid://` where the End-User wou= ld register their chosen provider as a protocol handler for the `openid:= //` scheme. However, again as a solution it's not without it's = challenges, notably; only a single registration at a time can be supported,= the actual identity of the provider remains blind to the RP until after th= e request is sent and it requires registration or some form of default hand= ling (e.g when there is no provider registered).

    How GNAP can sol= ve for this? I actually don't think this is core to GNAP, there may= be some considerations around discovery that are worth paying attention to= but not much in the core protocol design.


    SIOP doesn=E2=80=99t really solve the NASCAR issu= e since SIOP, by design, becomes yet one more login option among many. I th= ink GNAP can help this by enabling user-directed provider discovery to kick= off the process, but I agree that the core protocol doesn=E2=80=99t really= have much to say here, and shouldn=E2=80=99t.

    Exploring different deployment models = for the provider - This is the most frequently talked about aspect of S= IOP and perhaps the most interesting to GNAP. I like to think about the sco= pe of this issue as designing to allow for either a partially or fully dist= ributed/decentralized provider, rather than a centralized one (e.g an HTTP= =C2=A0based AuthZ server). As you noted this does come with its challenges = many of which are technical in nature, i.e how to appropriately address a d= ecentralized provider and what protocols are used to communicate with the p= rovider.

    How GNAP can solve for this? I think that's=C2= =A0what much of the discussion on this thread will be about and whether the= re is a hybrid model where some responsibility is still centrally administe= red like token issuance, while allowing other aspects to occur in a more di= stributed manner. Ideally though I'd like to see consideration for a co= mpletely distributed model too.

    I agree that this seems to be the most interesting place for overlap= . I don=E2=80=99t actually think the =E2=80=9Chybrid=E2=80=9D approach cent= ralizes things. Instead, you can think of the RS as having an associated AS= , and that AS accepting user consent and claims at runtime from a variety o= f sources (wallets, VCs, etc.). In this way, we aren=E2=80=99t talking abou= t a single AS in the world handling all of these requests, we=E2=80=99re ta= lking about a distributed network of AS=E2=80=99s associated with an even m= ore widely distributed set of RS=E2=80=99s. SSI and its associated technolo= gies would help these =E2=80=9Clocal=E2=80=9D AS=E2=80=99s issue access tok= ens without the RO needing to have an account, or even necessarily directly= interacting with the AS. There=E2=80=99s currently a technology gap there,= but my thoughts are that this is where the changes to the interaction mode= s section can really come to play.=C2=A0

    I think t= he notion of a non-HTTP AS is interesting, but I=E2=80=99m not sure if that= =E2=80=99s something GNAP ought to be solving for. I think that there=E2=80= =99s a deep value in building on top of HTTP for the core protocol, and not= abstracting away concepts from it. Otherwise, you end up re-inventing laye= rs, and you get something like SOAP all over again. :)

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


    Thanks,
    =
    3D"Mattr=C2=A0
    Tobias Looker=
    Mattr
    +64 (0) 27 378 0461
    tobias.looker@mattr.global
    =3D"Mattr3D"Mattr3D"Mattr=3D"Mattr

    This communication, in= cluding any attachments, is confidential. If you are not the intended recip= ient, you should not read it - please contact me immediately, destroy it, a= nd do not copy or use any part of this communication or disclose anything a= bout it. Thank you. Please note that this communication does not designate = an information system for the purposes of the Electronic Transactions Act 2= 002.


    On Thu, Feb 18, 2021 at 9:19 PM= Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi Justin,

    I= agree that defining AS role primarily as a token issuer is a fruitful idea= . Solving this problem well would also respond to the challenges discussed = previously on the list.=C2=A0

    Cheers
    Fabien=C2=A0


    Le mer. 17= f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:
    <= /div>
    The last interim call had a lot of discussion on= SSI technologies such as digital wallets, and how those fit with GNAP. I t= hink it=E2=80=99s worth continuing that conversation here on the list. Ther= e are a few issues in the tracker that give some background, too:

    <= /div>

    There=E2= =80=99s been a lot of interesting work recently in the OpenID Foundation ar= ound using the Self-issued OP (SIOP) functionality to bootstrap an SSI styl= e login. This makes extensive use of the implicit flow and front channel me= ssaging, but minimization of the front channel for message passing is a key= design tenet of GNAP (so much so that it=E2=80=99s included in our charter= ). Instead, GNAP has been built around an idea that everything starts the s= ame way: with an HTTP request to the AS.=C2=A0

    The= idea of an on-device AS has been brought up a lot, and we need to consider= if and how we want to deal with these kinds of use cases. The most obvious= way to address these would be to do some kind of clever off-HTTP hack like= SIOP, but keep in mind that even SIOP generally starts off with an HTTP-ba= sed discovery call by the RP to make things work.

    = My personal stance is that to do this, we need to re-evaluate our assumptio= ns about exactly what an AS does and what it needs to do those things. In O= Auth 2, it=E2=80=99s assumed that the AS is the device that=E2=80=99s authe= nticating the user, collecting consent, managing the client=E2=80=99s regis= tration, and creating an access token based on whatever set of rights that = are associated with all of those things. In UMA, this is turned around a bi= t by letting the RO present a bunch of nebulous =E2=80=9Cclaims=E2=80=9D in= teractively, but still at the AS.=C2=A0

    With both = of these, a key aspect remains: the AS needs to gather necessary informatio= n, and issue the access token (or identifiers/assertions). Because of how t= he protocol works, the client software now has a better opportunity to pres= ent information to the AS, either directly in the request or by introducing= the AS to another software component during the =E2=80=9Cinteraction=E2=80= =9D phase. So, what if we think of the AS primarily as a =E2=80=9Ctoken iss= uer=E2=80=9D?=C2=A0

    For example, if the client can= present a verifiable credential (VC) that represents the end user, the AS = can validate that VC and make an access token on behalf of that user, witho= ut having the user log in or interact with the AS at all. This VC can conta= in whatever access rights the token needs to represent, and the AS can tran= slate that into an artifact that the downstream RS=E2=80=99s can interpret,= without having to see the original VC or the user at all. The AS is still = HTTP based, but all the essential security and rights elements are provided= by the wallet. In this way, we can expand on the privacy-preserving aspect= s of OAuth and bridge the worlds of SSI and web APIs without violating the = basic nature of either.

    Coming from the OAuth worl= d, it feels weird to issue tokens like this, but there=E2=80=99s precedent = for this kind of thing. Today, a there are a number of service-based OAuth = AS's that are told what claims need to get put into the access token by= some trusted component. All of this happens outside the OAuth protocol. In= GNAP, I think it makes sense to account for this kind of thing in how we d= efine the protocol. That isn=E2=80=99t to say all of these pieces need to b= e defined in the core, but the base protocol ought to be able to handle bei= ng extended in this direction as needed.

    I=E2=80= =99m really interested to hear other people=E2=80=99s thoughts on how this = could come together.

    =C2=A0=E2=80=94 Justin
    <= /div>
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000008fdb5705bbb84673-- From nobody Fri Feb 19 18:03:45 2021 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 6E8F93A0D2A for ; Fri, 19 Feb 2021 18:03:44 -0800 (PST) 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 hSPpeElmQkEg for ; Fri, 19 Feb 2021 18:03:41 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 05E2E3A0D01 for ; Fri, 19 Feb 2021 18:03:40 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id q5so6082114ilc.10 for ; Fri, 19 Feb 2021 18:03:40 -0800 (PST) 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=lPN8IcYkCqjL0qd8jvSKhhL57+uLQQ9w+mnP8rcY46g=; b=SB9Ke6RlzHrqZ5rc7ALjzN0bZarX1A51iVZ+81rfDtDbCa6MyTyNA5BNGJGvDrtBZk vGAiR+w2EV02DAXPQ+YXjHTcej83o74Khw3TrEf1qeGVIrIuacYsa05ZgyJhpM0tCVfq IvchJ/Ro44XFflF37xKnjxxt74Zl7hHJR2mGJweYIE2cvgh38iXVHWSxZiOHMIVfZMIP RbfxPDssSsk5OwG05y4YP5HwufNPpmULyMurSpo/YgO+bQh6HLa+CP1G3WtxgOInudEv 8gz/3Td/+TT9TJ67uSxCwwLv5RV7oj/2R/pN7nGaO6ngJsTc/iTBEEGW+so/v5Pou3vt RTuA== 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=lPN8IcYkCqjL0qd8jvSKhhL57+uLQQ9w+mnP8rcY46g=; b=g92y8g5GnBhXdTiSbff1WhithLfk5om41WRXgwjxDIsLdIO2rVgCHAMEo9o239jPGI OlLhKlj/ViP2AuWSjdtaCSRqF1VvD82zBcLosEGd6aMfGT/mFiDqQ2EUpgyp9rOGMyX5 2xRiQSlXOzABvf/uAK8zu/V0h7kokTDOY6IlFB31OcXiTSJ7CHcAd/Of8SXLlT1ztE9u pbO0akprjfOS/PQbVF/ntuENpZHev/d+rXHIGAowRuxZkKCm/nCRXz+8iCzMc3yctxmu lvin6eBjj9wNLVPv/NzcRVa9iWjtbuL2jdY0tXvZcOEOJJtg3Jo0yxGNsgUDXFzq001F y94w== X-Gm-Message-State: AOAM5327Er8f0p3iGjgVrGLjIqjpquvUQ4I4EyHNrMcQs6q6F3OiGdKA I6JfeYks5LnTMGQ1CNi8zTPm32g+QiPuJqmQKsc= X-Google-Smtp-Source: ABdhPJyz56+LXznoSH9oRCzfXTZukKB48jm8fYi7ft4kcrWO/lNHnElmnN2kssXswN3vMP3t7eIOnvlmEhbJXZ8ioAw= X-Received: by 2002:a05:6e02:1a89:: with SMTP id k9mr6321194ilv.68.1613786620015; Fri, 19 Feb 2021 18:03:40 -0800 (PST) MIME-Version: 1.0 References: <6C0CBD9E-BE9B-47F7-8361-25785DCFDC82@mit.edu> In-Reply-To: From: Fabien Imbault Date: Sat, 20 Feb 2021 03:03:28 +0100 Message-ID: To: Adrian Gropper Cc: Justin Richer , Tobias Looker , txauth gnap Content-Type: multipart/alternative; boundary="0000000000003ab89605bbbafafc" Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2021 02:03:44 -0000 --0000000000003ab89605bbbafafc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adrian, "It's confusing to think that there are more RS than AS" frames the problem we're dealing with. I think it really depends on how we view the auth world today and in the future. Today there are many RSs providing specialized APIs. Openbanking is an obvious example. So we're speaking the order of magnitude of the number of organizational units for RSs, versus a few centralized IdPs and ASs. Notice that if we can design GNAP in a more modular fashion than OAuth2 by enabling multiple ASs, that would already be a fairly effective way to decentralize authorizations. Orgs are a well known target for privacy regulations, so we know what to expect, even if that's imperfect (of course bigtech regulation is still largely an unsolved problem, but laws are gradually evolving). Now there's another view, which is : each person should be operating its own AS and have its own wallet, as everyone has a phone. While I believe P. Sheldrake offers a few hints of why we should reflect on the social/ethical consequences of the technology (the generative vs self-sovereign identity debate, which I tried to summarize at https://fimbault.medium.com/the-ethical-dilemma-posed-by-decentralized-iden= tity-f8328b655544), it's quite clear that it is yet a prospective view. Wallets will need to be "crossing the chiasm". To ensure user privacy, what's the best path between an approach focused on orgs and self sovereignty (or whatever else we call the approach)? We might have preferences, but in practice it's hard to know what will happen and we might end-up with a mix of the 2, depending on the use case. Being fairly agnostic is really what GNAP can help with, and I think positioning the AS primarily as a "token issuer" enables that flexibility, all the more valuable in the face of uncertainty. There's also a technological readiness level to consider. We have years of experience with HTTP, we know how it can be used for our use case. We know its limitations. We know its future (HTTP/3). Which makes it a good candidate for an industrial standard. Building a fully decentralized alternative is anything but trivial. I'm not sure we should target fixing the web thanks to GNAP, an "hybrid" approach to decentralization (enabling communication with wallets) might be more realistic and focused. Whatever we choose, the goal I think is to clarify the expectations, and be open to work and align with other initiatives. Cheers Fabien Le ven. 19 f=C3=A9vr. 2021 =C3=A0 23:50, Adrian Gropper a =C3=A9crit : > I agree with the first two of Justin's responses but not the last one. > > It's confusing to think that there are more RS than AS. From a > human-centered (and hopefully IETF) perspective, each person might contro= l > or specify a different AS for each of their personas or for each child or > incompetent delegate of them as guardian. We're familiar with separate > gmail addresses for each persona. > > ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial > bitcoin wallet), or brokers (as in data brokers and surveillance > capitalism). Any RS that is willing to have a recurring relationship with= a > persona could accept a GNAP AS endpoint instead of an email address. This > is easiest using HTTP, but GNAP need not exclude other RS / AS APIs and > transports. Designing around the uncensored specification of one's AS as = a > human right would greatly simplify many aspects of GNAP adoption. > > That said, GNAP should not ignore the RS business or > jurisdictional reasons to limit the authority of the AS. UMA 2.0 spent > years dancing around this issue with ideas like "cascading" AS and variou= s > centralized or federated AS concepts. My conclusion is that any RS can > always do whatever it wants and there's not much the authorization protoc= ol > can help with other than specifying a notification endpoint so that an RS > can warn (and seek confirmation) or log various exceptions. This turns ou= t > to be, after a year of testimony, the regulation that applies to HIPAA RS > APIs in the US. For this reason GNAP might include a notification protoco= l > in the AS specification, or not. > > I propose that embracing a self-sovereign agent is key to harmonizing the > SSI and GNAP standards. > > Adrian > > On Fri, Feb 19, 2021 at 2:30 PM Justin Richer wrote: > >> Tobias, thanks for the great observations. Some reactions inline below. >> >> On Feb 18, 2021, at 7:59 PM, Tobias Looker >> wrote: >> >> Justin, >> >> I think this is a great and timely conversation to be having given the >> current interest around SSI and efforts like SIOP, I have been doing qui= te >> a bit of work in this space as of recent, so thought I'd add a few of th= e >> observations that I've made. >> >> In my opinion SIOP was really a bucket for solving quite a few different >> problems, not just one. In particular I think its intent was to solve 3 >> major ones: >> >> 1. Enabling portable identities >> 2. Solving the NASCAR problem >> 3. Exploring different deployment models for the provider >> >> To drill down briefly on these, note much of my terminology is OpenID >> based due to SIOPs origin >> >> *Enabling portable identities *- In general today in the case of OpenID, >> the end-users identity as understood by a relying party is scoped within >> the domain of the provider. Which means if that provider goes out of >> business or for whatever reason decides to no longer offer the same >> identity services to the End-User, their identity is essentially gone. >> Whilst there has been some interesting related work from groups like MOD= RNA >> on solutions to combat this like 'Account Porting', they often assume th= e >> old provider remains online and willing to facilitate in the account >> porting process so that the End-User can migrate to a new provider. SIOP >> actually elected to do something different here by using cryptography, >> instead of the End-User identifier being something like a GUID asserted >> within the domain of the provider, SIOP defined this instead as a public >> key fingerprint associated to a private key that's assumed to be under t= he >> control of the user. In doing so the identity itself becomes portable >> between providers by transferring the associated private key. Now this >> approach does have drawbacks and arguably encourages what many would ref= er >> to as bad cryptographic practise by not allowing any way to do key >> rotation, however the idea was there. >> >> *How GNAP can solve for this?* By having flexibility around how the >> resource owner / End-User is referred to by the Authorization server (e.= g >> allow the identifier to be something like a public key or a resolvable >> identifier to public keys such as a DID) >> >> >> I personally think that GNAP should be a flexible :carrier: of >> identifiers and other bits of identity information. This is the main rea= son >> we went with the Subject Identifiers draft from SECEVENT: it=E2=80=99s s= et up to >> talk about a variety of different kinds of identifiers, all of them >> asserted in the context of the AS. If there=E2=80=99s a definition for a= DID URL or >> a JWK in the sub_ids object structure, GNAP would be able to just use it >> directly alongside every other format. I haven=E2=80=99t seen those prop= osed yet, >> but it would be easy to do and, in my mind, would be a better solution t= han >> the portable identifiers proposal that was recently brought up in the FA= PI >> working group in OIDF. (A side note, but the main problem I have here is >> that it=E2=80=99s pasting semantics and formats onto a field where none = existed >> before, and that=E2=80=99s rife for problems. Better to have a structure= that takes >> that into account from the start, in my view.) >> >> >> *Solving the NASCAR problem *- One of those enduring problems in >> identity systems, which I think is really about the three way negotiatio= n >> going on between the RP, the End-User and the Provider. SIOP's solution >> pushed for most of the power in this decision making process to lie with >> the End-User, letting them decide who they want as their provider rather >> than RP's providing an enumeration of who they support via provider icon= s >> on their login page and End-Users having to select from those options. I= t >> accomplished this via using a custom URL scheme of `openid://` where the >> End-User would register their chosen provider as a protocol handler for = the >> `openid://` scheme. However, again as a solution it's not without it's >> challenges, notably; only a single registration at a time can be support= ed, >> the actual identity of the provider remains blind to the RP until after = the >> request is sent and it requires registration or some form of default >> handling (e.g when there is no provider registered). >> >> *How GNAP can solve for this?* I actually don't think this is core to >> GNAP, there may be some considerations around discovery that are worth >> paying attention to but not much in the core protocol design. >> >> >> SIOP doesn=E2=80=99t really solve the NASCAR issue since SIOP, by design= , becomes >> yet one more login option among many. I think GNAP can help this by >> enabling user-directed provider discovery to kick off the process, but I >> agree that the core protocol doesn=E2=80=99t really have much to say her= e, and >> shouldn=E2=80=99t. >> >> *Exploring different deployment models for the provider* - This is the >> most frequently talked about aspect of SIOP and perhaps the most >> interesting to GNAP. I like to think about the scope of this issue as >> designing to allow for either a partially or fully >> distributed/decentralized provider, rather than a centralized one (e.g a= n >> HTTP based AuthZ server). As you noted this does come with its challenge= s >> many of which are technical in nature, i.e how to appropriately address = a >> decentralized provider and what protocols are used to communicate with t= he >> provider. >> >> *How GNAP can solve for this?* I think that's what much of the >> discussion on this thread will be about and whether there is a hybrid mo= del >> where some responsibility is still centrally administered like token >> issuance, while allowing other aspects to occur in a more distributed >> manner. Ideally though I'd like to see consideration for a completely >> distributed model too. >> >> >> I agree that this seems to be the most interesting place for overlap. I >> don=E2=80=99t actually think the =E2=80=9Chybrid=E2=80=9D approach centr= alizes things. Instead, you >> can think of the RS as having an associated AS, and that AS accepting us= er >> consent and claims at runtime from a variety of sources (wallets, VCs, >> etc.). In this way, we aren=E2=80=99t talking about a single AS in the w= orld >> handling all of these requests, we=E2=80=99re talking about a distribute= d network >> of AS=E2=80=99s associated with an even more widely distributed set of R= S=E2=80=99s. SSI >> and its associated technologies would help these =E2=80=9Clocal=E2=80=9D= AS=E2=80=99s issue access >> tokens without the RO needing to have an account, or even necessarily >> directly interacting with the AS. There=E2=80=99s currently a technology= gap there, >> but my thoughts are that this is where the changes to the interaction mo= des >> section can really come to play. >> >> I think the notion of a non-HTTP AS is interesting, but I=E2=80=99m not = sure if >> that=E2=80=99s something GNAP ought to be solving for. I think that ther= e=E2=80=99s a deep >> value in building on top of HTTP for the core protocol, and not abstract= ing >> away concepts from it. Otherwise, you end up re-inventing layers, and yo= u >> get something like SOAP all over again. :) >> >> =E2=80=94 Justin >> >> >> Thanks, >> [image: Mattr website] >> *Tobias Looker* >> Mattr >> +64 (0) 27 378 0461 >> tobias.looker@mattr.global >> [image: Mattr website] [image: Mattr on LinkedIn= ] >> [image: Mattr on Twitter] >> [image: Mattr on Github] >> >> This communication, including any attachments, is confidential. If you >> are not the intended recipient, you should not read it - please contact = me >> immediately, destroy it, and do not copy or use any part of this >> communication or disclose anything about it. Thank you. Please note that >> this communication does not designate an information system for the >> purposes of the Electronic Transactions Act 2002. >> >> >> On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault >> wrote: >> >>> Hi Justin, >>> >>> I agree that defining AS role primarily as a token issuer is a fruitful >>> idea. Solving this problem well would also respond to the challenges >>> discussed previously on the list. >>> >>> Cheers >>> Fabien >>> >>> >>> Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer a =C3=A9crit : >>> >>>> The last interim call had a lot of discussion on SSI technologies such >>>> as digital wallets, and how those fit with GNAP. I think it=E2=80=99s = worth >>>> continuing that conversation here on the list. There are a few issues = in >>>> the tracker that give some background, too: >>>> >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 >>>> >>>> There=E2=80=99s been a lot of interesting work recently in the OpenID >>>> Foundation around using the Self-issued OP (SIOP) functionality to >>>> bootstrap an SSI style login. This makes extensive use of the implicit= flow >>>> and front channel messaging, but minimization of the front channel for >>>> message passing is a key design tenet of GNAP (so much so that it=E2= =80=99s >>>> included in our charter). Instead, GNAP has been built around an idea = that >>>> everything starts the same way: with an HTTP request to the AS. >>>> >>>> The idea of an on-device AS has been brought up a lot, and we need to >>>> consider if and how we want to deal with these kinds of use cases. The= most >>>> obvious way to address these would be to do some kind of clever off-HT= TP >>>> hack like SIOP, but keep in mind that even SIOP generally starts off w= ith >>>> an HTTP-based discovery call by the RP to make things work. >>>> >>>> My personal stance is that to do this, we need to re-evaluate our >>>> assumptions about exactly what an AS does and what it needs to do thos= e >>>> things. In OAuth 2, it=E2=80=99s assumed that the AS is the device tha= t=E2=80=99s >>>> authenticating the user, collecting consent, managing the client=E2=80= =99s >>>> registration, and creating an access token based on whatever set of ri= ghts >>>> that are associated with all of those things. In UMA, this is turned a= round >>>> a bit by letting the RO present a bunch of nebulous =E2=80=9Cclaims=E2= =80=9D interactively, >>>> but still at the AS. >>>> >>>> With both of these, a key aspect remains: the AS needs to gather >>>> necessary information, and issue the access token (or >>>> identifiers/assertions). Because of how the protocol works, the client >>>> software now has a better opportunity to present information to the AS= , >>>> either directly in the request or by introducing the AS to another sof= tware >>>> component during the =E2=80=9Cinteraction=E2=80=9D phase. So, what if = we think of the AS >>>> primarily as a =E2=80=9Ctoken issuer=E2=80=9D? >>>> >>>> For example, if the client can present a verifiable credential (VC) >>>> that represents the end user, the AS can validate that VC and make an >>>> access token on behalf of that user, without having the user log in or >>>> interact with the AS at all. This VC can contain whatever access right= s the >>>> token needs to represent, and the AS can translate that into an artifa= ct >>>> that the downstream RS=E2=80=99s can interpret, without having to see = the original >>>> VC or the user at all. The AS is still HTTP based, but all the essenti= al >>>> security and rights elements are provided by the wallet. In this way, = we >>>> can expand on the privacy-preserving aspects of OAuth and bridge the w= orlds >>>> of SSI and web APIs without violating the basic nature of either. >>>> >>>> Coming from the OAuth world, it feels weird to issue tokens like this, >>>> but there=E2=80=99s precedent for this kind of thing. Today, a there a= re a number >>>> of service-based OAuth AS's that are told what claims need to get put = into >>>> the access token by some trusted component. All of this happens outsid= e the >>>> OAuth protocol. In GNAP, I think it makes sense to account for this ki= nd of >>>> thing in how we define the protocol. That isn=E2=80=99t to say all of = these pieces >>>> need to be defined in the core, but the base protocol ought to be able= to >>>> handle being extended in this direction as needed. >>>> >>>> I=E2=80=99m really interested to hear other people=E2=80=99s thoughts = on how this could >>>> come together. >>>> >>>> =E2=80=94 Justin >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> This communication, including any attachments, is confidential. If you a= re not the intended recipient, you should not read it - please contact me i= mmediately, destroy it, and do not copy or use any part of this communicati= on or disclose anything about it. Thank you. Please note that this communic= ation does not designate an information system for the purposes of the Elec= tronic Transactions Act 2002. >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000003ab89605bbbafafc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Adrian,=C2=A0

    <= /div>
    "It's confusing to think that there are mor= e RS than AS" frames the problem we're dealing with.=C2=A0
    I think it really depends on how we view the auth world tod= ay and in the future.=C2=A0

    Today there are many RSs providi= ng specialized APIs. Openbanking is an obvious example. So we're speaki= ng the order of magnitude of the number of organizational units for RSs, ve= rsus a few centralized IdPs and ASs.
    Notice that if we can design GNAP in a= =C2=A0 more modular fashion than OAuth2 by enabling multiple ASs, that=C2= =A0would already be a fairly effective way to decentralize authoriza= tions. Orgs are a well known target for privacy regulations, so we know wha= t to expect, even if that's imperfect (of course bigtech regulation is = still largely an unsolved problem, but laws are gradually evolving).=C2=A0<= /div>

    Now there's another view, which is : each person = should be operating its own AS and have its own wallet, as everyone has a p= hone.=C2=A0
    While I believe P. Sheldrake offers a fe= w hints of why we should reflect on the social/ethical consequences of the = technology (the generative vs self-sovereign identity debate, which I tried= to summarize at https://fimbault.medium.com/= the-ethical-dilemma-posed-by-decentralized-identity-f8328b655544), it&#= 39;s quite clear that it is yet a prospective view. Wallets will need to be= "crossing the chiasm".=C2=A0

    To ensure user privacy, what's the best path between an= approach focused on orgs and self sovereignty (or whatever else we call th= e approach)? We might have preferences, but in practice it's hard to kn= ow what will happen and we might end-up with a mix of the 2, depending on t= he use case.=C2=A0
    Being fairly agnostic is really w= hat GNAP can help with, and I think positioning the AS primarily as a "= ;token issuer" enables that flexibility, all the more valuable in the = face of uncertainty.=C2=A0

    There's also a technological readiness level to consider. We have ye= ars of experience with HTTP, we know how it can be used for our use case. W= e know its limitations. We know its future (HTTP/3). Which makes it a good = candidate for an industrial standard.=C2=A0

    Building a fully decentralized alternative is anything = but trivial. I'm not sure we should target fixing the web thanks to GNA= P, an=C2=A0"hybrid" approa= ch to decentralization (enabling communication with wallets) might be more = realistic and focused.=C2=A0

    Whatever we choose, the goal I think is to clarify th= e expectations, and be open to work and align with other initiatives.=C2=A0=

    Cheers=C2=A0
    Fabien=C2=A0


    Le ven. 19 f=C3=A9vr. 2021= =C3=A0 23:50, Adrian Gropper <agropper@healthurl.com> a =C3= =A9crit=C2=A0:
    I a= gree with the=C2=A0first=C2=A0two of Justin's responses but not the las= t one.

    It's confusing to think that there are more R= S than AS. From a human-centered (and hopefully IETF) perspective, each per= son might control or specify a different AS for each of their personas or f= or each child or incompetent delegate of them as guardian. We're famili= ar with separate gmail addresses for each persona.

    ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial bitco= in wallet), or brokers (as in data brokers and surveillance capitalism). An= y RS that is willing to have a recurring relationship with a persona could = accept a GNAP AS endpoint instead of an email address. This is easiest usin= g HTTP, but GNAP need not exclude other RS / AS APIs and transports. Design= ing around the uncensored specification=C2=A0of one's AS as a human rig= ht would greatly simplify many aspects of GNAP adoption.

    That said, GNAP should not ignore the RS business or jurisdictional= =C2=A0reasons to limit the authority of the AS. UMA 2.0 spent years dancing= around this issue with ideas like "cascading" AS and various cen= tralized or federated AS concepts. My conclusion is that any RS can always = do whatever it wants and there's not much the authorization protocol ca= n help with other than specifying a notification endpoint so that an RS can= warn (and seek confirmation) or log various exceptions. This turns out to = be, after a year of testimony, the regulation that applies to HIPAA RS APIs= in the US. For this reason GNAP might include a notification protocol in t= he AS specification, or not.

    I propose that embrac= ing a self-sovereign agent is key to harmonizing the SSI and GNAP standards= .

    Adrian

    On Fri, Feb 19, 2021 at 2:30 PM Just= in Richer <jricher@mit.edu> wrote:
    Tobias= , thanks for the great observations. Some reactions inline below.
    <= br>
    On Feb 18, 2021, at 7:59 PM, Tobias Looke= r <tobias.looker@mattr.global> wrote:
    Justin,

    I think this is a great and timely co= nversation to be having given the current interest around SSI and efforts l= ike SIOP, I have been doing quite a bit of work in this space as of recent,= so thought I'd add a few of the observations that I've made.
    In my opinion SIOP was really a bucket for solving quite a few different = problems, not just one. In particular I think its intent was to solve 3 maj= or ones:

    1. Enabling portable identities
    2. Solving the NASCAR pr= oblem
    3. Exploring different deployment models for the provider

    T= o drill down briefly on these, note much of my terminology is OpenID based = due to SIOPs origin=C2=A0

    Enabling portable identities - In g= eneral today in the case of OpenID, the end-users identity as understood by= a relying party is scoped within the domain of the provider. Which means i= f that provider goes out of business or for whatever reason decides to no l= onger offer the same identity services to the End-User, their identity is e= ssentially gone. Whilst there has been some interesting related work from g= roups like MODRNA on solutions to combat this like 'Account Porting'= ;, they often assume the old provider remains online and willing to facilit= ate in the account porting process so that the End-User can migrate to a ne= w provider. SIOP actually elected to do something different here by using c= ryptography, instead of the End-User identifier being something like a GUID= asserted within the domain of the provider, SIOP defined this instead as a= public key fingerprint associated to a private key that's assumed to b= e under the control of the user. In doing so the identity itself becomes po= rtable between providers by transferring the associated private key. Now th= is approach does have drawbacks and arguably encourages what many would ref= er to as bad cryptographic practise by not allowing any way to do key rotat= ion, however the idea was there.=C2=A0

    How GNAP can s= olve for this? By having flexibility around how the resource owner / En= d-User is referred to by the Authorization server (e.g allow the identifier= to be something like a public key or a resolvable identifier to public key= s such as a DID)

    I pe= rsonally think that GNAP should be a flexible :carrier: of identifiers and = other bits of identity information. This is the main reason we went with th= e Subject Identifiers draft from SECEVENT: it=E2=80=99s set up to talk abou= t a variety of different kinds of identifiers, all of them asserted in the = context of the AS. If there=E2=80=99s a definition for a DID URL or a JWK i= n the sub_ids object structure, GNAP would be able to just use it directly = alongside every other format. I haven=E2=80=99t seen those proposed yet, bu= t it would be easy to do and, in my mind, would be a better solution than t= he portable identifiers proposal that was recently brought up in the FAPI w= orking group in OIDF. (A side note, but the main problem I have here is tha= t it=E2=80=99s pasting semantics and formats onto a field where none existe= d before, and that=E2=80=99s rife for problems. Better to have a structure = that takes that into account from the start, in my view.)


    Solving the NASCAR prob= lem - One of those enduring problems in identity systems, which I think= is really about the three way negotiation going on between the RP, the End= -User and the Provider. SIOP's solution pushed for most of the power in= this decision making process to lie with the End-User, letting them decide= who they want as their provider rather than RP's providing an enumerat= ion of who they support via provider icons on their login page and End-User= s having to select from those options. It accomplished this via using a cus= tom URL scheme of `openid://` where th= e End-User would register their chosen provider as a protocol handler for t= he `openid://` scheme. However, again = as a solution it's not without it's challenges, notably; only a sin= gle registration at a time can be supported, the actual identity of the pro= vider remains blind to the RP until after the request is sent and it requir= es registration or some form of default handling (e.g when there is no prov= ider registered).

    How GNAP can solve for this? I actually don= 't think this is core to GNAP, there may be some considerations around = discovery that are worth paying attention to but not much in the core proto= col design.


    SIOP = doesn=E2=80=99t really solve the NASCAR issue since SIOP, by design, become= s yet one more login option among many. I think GNAP can help this by enabl= ing user-directed provider discovery to kick off the process, but I agree t= hat the core protocol doesn=E2=80=99t really have much to say here, and sho= uldn=E2=80=99t.

    Exploring different deployment models for the provider - This is = the most frequently talked about aspect of SIOP and perhaps the most intere= sting to GNAP. I like to think about the scope of this issue as designing t= o allow for either a partially or fully distributed/decentralized provider,= rather than a centralized one (e.g an HTTP=C2=A0based AuthZ server). As yo= u noted this does come with its challenges many of which are technical in n= ature, i.e how to appropriately address a decentralized provider and what p= rotocols are used to communicate with the provider.

    How GNAP can= solve for this? I think that's=C2=A0what much of the discussion on= this thread will be about and whether there is a hybrid model where some r= esponsibility is still centrally administered like token issuance, while al= lowing other aspects to occur in a more distributed manner. Ideally though = I'd like to see consideration for a completely distributed model too.

    I agree that this seems to= be the most interesting place for overlap. I don=E2=80=99t actually think = the =E2=80=9Chybrid=E2=80=9D approach centralizes things. Instead, you can = think of the RS as having an associated AS, and that AS accepting user cons= ent and claims at runtime from a variety of sources (wallets, VCs, etc.). I= n this way, we aren=E2=80=99t talking about a single AS in the world handli= ng all of these requests, we=E2=80=99re talking about a distributed network= of AS=E2=80=99s associated with an even more widely distributed set of RS= =E2=80=99s. SSI and its associated technologies would help these =E2=80=9Cl= ocal=E2=80=9D AS=E2=80=99s issue access tokens without the RO needing to ha= ve an account, or even necessarily directly interacting with the AS. There= =E2=80=99s currently a technology gap there, but my thoughts are that this = is where the changes to the interaction modes section can really come to pl= ay.=C2=A0

    I think the notion of a non-HTTP AS is i= nteresting, but I=E2=80=99m not sure if that=E2=80=99s something GNAP ought= to be solving for. I think that there=E2=80=99s a deep value in building o= n top of HTTP for the core protocol, and not abstracting away concepts from= it. Otherwise, you end up re-inventing layers, and you get something like = SOAP all over again. :)

    =C2=A0=E2=80=94 Justin

    Thanks,
    3D"Mattr=C2=A0=
    Tobias Looker<= br>
    Mattr
    +64 (0) 27 378 0461
    tobias.looker@mattr.global
    3D"Mattr3D"Mattr3D"Mattr3D"Mattr

    This communication, including any attachments, = is confidential. If you are not the intended recipient, you should not read= it - please contact me immediately, destroy it, and do not copy or use any= part of this communication or disclose anything about it. Thank you. Pleas= e note that this communication does not designate an information system for= the purposes of the Electronic Transactions Act 2002.


    On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justin,

    I agree that defining AS role primarily as a token issuer is a fruitful i= dea. Solving this problem well would also respond to the challenges discuss= ed previously on the list.=C2=A0

    Cheers
    Fabien=C2=A0


    Le mer= . 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer <jricher@mit.ed= u> a =C3=A9crit=C2=A0:
    The last inter= im call had a lot of discussion on SSI technologies such as digital wallets= , and how those fit with GNAP. I think it=E2=80=99s worth continuing that c= onversation here on the list. There are a few issues in the tracker that gi= ve some background, too:


    There=E2=80=99s been a lot = of interesting work recently in the OpenID Foundation around using the Self= -issued OP (SIOP) functionality to bootstrap an SSI style login. This makes= extensive use of the implicit flow and front channel messaging, but minimi= zation of the front channel for message passing is a key design tenet of GN= AP (so much so that it=E2=80=99s included in our charter). Instead, GNAP ha= s been built around an idea that everything starts the same way: with an HT= TP request to the AS.=C2=A0

    The idea of an on-devi= ce AS has been brought up a lot, and we need to consider if and how we want= to deal with these kinds of use cases. The most obvious way to address the= se would be to do some kind of clever off-HTTP hack like SIOP, but keep in = mind that even SIOP generally starts off with an HTTP-based discovery call = by the RP to make things work.

    My personal stance = is that to do this, we need to re-evaluate our assumptions about exactly wh= at an AS does and what it needs to do those things. In OAuth 2, it=E2=80=99= s assumed that the AS is the device that=E2=80=99s authenticating the user,= collecting consent, managing the client=E2=80=99s registration, and creati= ng an access token based on whatever set of rights that are associated with= all of those things. In UMA, this is turned around a bit by letting the RO= present a bunch of nebulous =E2=80=9Cclaims=E2=80=9D interactively, but st= ill at the AS.=C2=A0

    With both of these, a key asp= ect remains: the AS needs to gather necessary information, and issue the ac= cess token (or identifiers/assertions). Because of how the protocol works, = the client software now has a better opportunity to present information to = the AS, either directly in the request or by introducing the AS to another = software component during the =E2=80=9Cinteraction=E2=80=9D phase. So, what= if we think of the AS primarily as a =E2=80=9Ctoken issuer=E2=80=9D?=C2=A0=

    For example, if the client can present a verifiab= le credential (VC) that represents the end user, the AS can validate that V= C and make an access token on behalf of that user, without having the user = log in or interact with the AS at all. This VC can contain whatever access = rights the token needs to represent, and the AS can translate that into an = artifact that the downstream RS=E2=80=99s can interpret, without having to = see the original VC or the user at all. The AS is still HTTP based, but all= the essential security and rights elements are provided by the wallet. In = this way, we can expand on the privacy-preserving aspects of OAuth and brid= ge the worlds of SSI and web APIs without violating the basic nature of eit= her.

    Coming from the OAuth world, it feels weird t= o issue tokens like this, but there=E2=80=99s precedent for this kind of th= ing. Today, a there are a number of service-based OAuth AS's that are t= old what claims need to get put into the access token by some trusted compo= nent. All of this happens outside the OAuth protocol. In GNAP, I think it m= akes sense to account for this kind of thing in how we define the protocol.= That isn=E2=80=99t to say all of these pieces need to be defined in the co= re, but the base protocol ought to be able to handle being extended in this= direction as needed.

    I=E2=80=99m really intereste= d to hear other people=E2=80=99s thoughts on how this could come together.<= /div>

    =C2=A0=E2=80=94 Justin
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --0000000000003ab89605bbbafafc-- From nobody Fri Feb 19 20:20:17 2021 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 E50083A0D08 for ; Fri, 19 Feb 2021 20:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 lB47ufqzJJCf for ; Fri, 19 Feb 2021 20:20:11 -0800 (PST) Received: from mail-vk1-f179.google.com (mail-vk1-f179.google.com [209.85.221.179]) (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 BA9A23A0CFF for ; Fri, 19 Feb 2021 20:20:10 -0800 (PST) Received: by mail-vk1-f179.google.com with SMTP id v66so1664488vkd.10 for ; Fri, 19 Feb 2021 20:20:10 -0800 (PST) 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=6IF7eRVj5bnDMIQK7aZ3aPzfOR7cANtlwQsLBrlisyo=; b=q1zOCQe1H1o8PgZfg/I9Dm550AEhoAkNbmM9REgHPl/sWNGWmppVoYIKCpsEHLJSWe KAnNePkMtxbWSNrCm3sDLASAHVwd/rM2F9Cmxe/ZPKeuEEvg5zuTnQDeAU+WIbHZGDRJ A9CluFhKCl/mYVVLpJoaXLr6UFM/EPAA4acrrWvrLuaaJmkRrz32Lm3a2q8L2aD/u6Qk dmyaMzQj4fVt8J6NSia8jodxIbj6TzS8YyxnHwIIy1SSjJqZnhLHBUeqBKEat/UmA4+G WOsf/5CDNGKwShNr2VMeG5PHJvODjpjTSm1AKDtw4Y0Q8sdmNqRnVLKPH6w+RdQjdYO+ U6UA== X-Gm-Message-State: AOAM53173AHipebpfYTYv/raLRIivFChKf9a0sfqupORkf+K3OP3fIhE 8Iq8SESRO2TGjzjgiCWR7pSzI8F06M5MveBrkjY= X-Google-Smtp-Source: ABdhPJx8QwDcxm7jzqXAN7E8vXP2Hx/yxl5RuMTFVFkc4iPm5ZB2zLPh+kCHZNUnzPoZ1NxPpQ2pbLECylD8rjzfYEI= X-Received: by 2002:a1f:a9c9:: with SMTP id s192mr9600142vke.22.1613794809306; Fri, 19 Feb 2021 20:20:09 -0800 (PST) MIME-Version: 1.0 References: <6C0CBD9E-BE9B-47F7-8361-25785DCFDC82@mit.edu> In-Reply-To: From: Adrian Gropper Date: Fri, 19 Feb 2021 23:19:57 -0500 Message-ID: To: Fabien Imbault Cc: txauth gnap , Justin Richer , Tobias Looker Content-Type: multipart/alternative; boundary="000000000000595fc405bbbce204" Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2021 04:20:15 -0000 --000000000000595fc405bbbce204 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Fabien, I don't disagree with the idea that GNAP should not presume the adoption of SSI standards or philosophy. (P. Sheldrake and I are pals and I'm an informal channel between EFF and some SSI workgroups.) I do believe that RS and data brokers have a growing security problem that only Zero-Trust Architecture can do much to solve. Mobile wallets are essential to provide the non repudiable signatures (regardless of how credentials are managed for privacy) and this will tend to facilitate some decentralization even if it would not come naturally to the RS enterprise. The SSI standards will apply to growing ZTA. ZTA cannot work just between wallet and RS. It needs delegation, notarization, and audit. Therefore, I see GNAP as playing the central role. >From this ZTA perspective, rather than privacy or decentralization as an abstract goal, the question of whether there are more or fewer ASs than wallets is arguable. One guardian on the RO side or one "associate" on the RS side could easily each have as many AS as they have wallets. Their ASs represent personas and semi-autonomous agents. Their multiple wallets represent redundant user agent devices each with a separate biometrically locked HSM. In an enterprise (RS or data broker) ZTA system, the delegation target may tend to look more like an agent (AS) or client (RC) than like a wallet. For example, in healthcare the guardians and associates control wallets and AS agents as the target of delegation (workflow) while the enterprise electronic health record looks more like a client to various RSs. With ZTA, the RSs will be both in and out of the control of the enterprise. I've summarized the relationship between wallets, AS, RC, and RS as 6 use-cases in this short set of slides: https://docs.google.com/presentation/d/1ksKal62ZiApX09Nejm4RSqHzHJbgwpu_l2H= o64_ePKU/edit#slide=3Did.gb2d2b0f28a_0_0 I hope this clarifies some expectations and where GNAP needs to align with other initiatives. Adrian On Fri, Feb 19, 2021 at 9:03 PM Fabien Imbault wrote: > Hi Adrian, > > "It's confusing to think that there are more RS than AS" frames the > problem we're dealing with. > I think it really depends on how we view the auth world today and in the > future. > > Today there are many RSs providing specialized APIs. Openbanking is an > obvious example. So we're speaking the order of magnitude of the number o= f > organizational units for RSs, versus a few centralized IdPs and ASs. > Notice that if we can design GNAP in a more modular fashion than OAuth2 > by enabling multiple ASs, that would already be a fairly effective way to > decentralize authorizations. Orgs are a well known target for privacy > regulations, so we know what to expect, even if that's imperfect (of cour= se > bigtech regulation is still largely an unsolved problem, but laws are > gradually evolving). > > Now there's another view, which is : each person should be operating its > own AS and have its own wallet, as everyone has a phone. > While I believe P. Sheldrake offers a few hints of why we should reflect > on the social/ethical consequences of the technology (the generative vs > self-sovereign identity debate, which I tried to summarize at > https://fimbault.medium.com/the-ethical-dilemma-posed-by-decentralized-id= entity-f8328b655544), > it's quite clear that it is yet a prospective view. Wallets will need to = be > "crossing the chiasm". > > To ensure user privacy, what's the best path between an approach focused > on orgs and self sovereignty (or whatever else we call the approach)? We > might have preferences, but in practice it's hard to know what will happe= n > and we might end-up with a mix of the 2, depending on the use case. > Being fairly agnostic is really what GNAP can help with, and I think > positioning the AS primarily as a "token issuer" enables that flexibility= , > all the more valuable in the face of uncertainty. > > There's also a technological readiness level to consider. We have years o= f > experience with HTTP, we know how it can be used for our use case. We kno= w > its limitations. We know its future (HTTP/3). Which makes it a good > candidate for an industrial standard. > > Building a fully decentralized alternative is anything but trivial. I'm > not sure we should target fixing the web thanks to GNAP, an "hybrid" > approach to decentralization (enabling communication with wallets) might = be > more realistic and focused. > > Whatever we choose, the goal I think is to clarify the expectations, and > be open to work and align with other initiatives. > > Cheers > Fabien > > > Le ven. 19 f=C3=A9vr. 2021 =C3=A0 23:50, Adrian Gropper a > =C3=A9crit : > >> I agree with the first two of Justin's responses but not the last one. >> >> It's confusing to think that there are more RS than AS. From a >> human-centered (and hopefully IETF) perspective, each person might contr= ol >> or specify a different AS for each of their personas or for each child o= r >> incompetent delegate of them as guardian. We're familiar with separate >> gmail addresses for each persona. >> >> ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial >> bitcoin wallet), or brokers (as in data brokers and surveillance >> capitalism). Any RS that is willing to have a recurring relationship wit= h a >> persona could accept a GNAP AS endpoint instead of an email address. Thi= s >> is easiest using HTTP, but GNAP need not exclude other RS / AS APIs and >> transports. Designing around the uncensored specification of one's AS as= a >> human right would greatly simplify many aspects of GNAP adoption. >> >> That said, GNAP should not ignore the RS business or >> jurisdictional reasons to limit the authority of the AS. UMA 2.0 spent >> years dancing around this issue with ideas like "cascading" AS and vario= us >> centralized or federated AS concepts. My conclusion is that any RS can >> always do whatever it wants and there's not much the authorization proto= col >> can help with other than specifying a notification endpoint so that an R= S >> can warn (and seek confirmation) or log various exceptions. This turns o= ut >> to be, after a year of testimony, the regulation that applies to HIPAA R= S >> APIs in the US. For this reason GNAP might include a notification protoc= ol >> in the AS specification, or not. >> >> I propose that embracing a self-sovereign agent is key to harmonizing th= e >> SSI and GNAP standards. >> >> Adrian >> >> On Fri, Feb 19, 2021 at 2:30 PM Justin Richer wrote: >> >>> Tobias, thanks for the great observations. Some reactions inline below. >>> >>> On Feb 18, 2021, at 7:59 PM, Tobias Looker >>> wrote: >>> >>> Justin, >>> >>> I think this is a great and timely conversation to be having given the >>> current interest around SSI and efforts like SIOP, I have been doing qu= ite >>> a bit of work in this space as of recent, so thought I'd add a few of t= he >>> observations that I've made. >>> >>> In my opinion SIOP was really a bucket for solving quite a few differen= t >>> problems, not just one. In particular I think its intent was to solve 3 >>> major ones: >>> >>> 1. Enabling portable identities >>> 2. Solving the NASCAR problem >>> 3. Exploring different deployment models for the provider >>> >>> To drill down briefly on these, note much of my terminology is OpenID >>> based due to SIOPs origin >>> >>> *Enabling portable identities *- In general today in the case of >>> OpenID, the end-users identity as understood by a relying party is scop= ed >>> within the domain of the provider. Which means if that provider goes ou= t of >>> business or for whatever reason decides to no longer offer the same >>> identity services to the End-User, their identity is essentially gone. >>> Whilst there has been some interesting related work from groups like MO= DRNA >>> on solutions to combat this like 'Account Porting', they often assume t= he >>> old provider remains online and willing to facilitate in the account >>> porting process so that the End-User can migrate to a new provider. SIO= P >>> actually elected to do something different here by using cryptography, >>> instead of the End-User identifier being something like a GUID asserted >>> within the domain of the provider, SIOP defined this instead as a publi= c >>> key fingerprint associated to a private key that's assumed to be under = the >>> control of the user. In doing so the identity itself becomes portable >>> between providers by transferring the associated private key. Now this >>> approach does have drawbacks and arguably encourages what many would re= fer >>> to as bad cryptographic practise by not allowing any way to do key >>> rotation, however the idea was there. >>> >>> *How GNAP can solve for this?* By having flexibility around how the >>> resource owner / End-User is referred to by the Authorization server (e= .g >>> allow the identifier to be something like a public key or a resolvable >>> identifier to public keys such as a DID) >>> >>> >>> I personally think that GNAP should be a flexible :carrier: of >>> identifiers and other bits of identity information. This is the main re= ason >>> we went with the Subject Identifiers draft from SECEVENT: it=E2=80=99s = set up to >>> talk about a variety of different kinds of identifiers, all of them >>> asserted in the context of the AS. If there=E2=80=99s a definition for = a DID URL or >>> a JWK in the sub_ids object structure, GNAP would be able to just use i= t >>> directly alongside every other format. I haven=E2=80=99t seen those pro= posed yet, >>> but it would be easy to do and, in my mind, would be a better solution = than >>> the portable identifiers proposal that was recently brought up in the F= API >>> working group in OIDF. (A side note, but the main problem I have here i= s >>> that it=E2=80=99s pasting semantics and formats onto a field where none= existed >>> before, and that=E2=80=99s rife for problems. Better to have a structur= e that takes >>> that into account from the start, in my view.) >>> >>> >>> *Solving the NASCAR problem *- One of those enduring problems in >>> identity systems, which I think is really about the three way negotiati= on >>> going on between the RP, the End-User and the Provider. SIOP's solution >>> pushed for most of the power in this decision making process to lie wit= h >>> the End-User, letting them decide who they want as their provider rathe= r >>> than RP's providing an enumeration of who they support via provider ico= ns >>> on their login page and End-Users having to select from those options. = It >>> accomplished this via using a custom URL scheme of `openid://` where >>> the End-User would register their chosen provider as a protocol handler= for >>> the `openid://` scheme. However, again as a solution it's not without >>> it's challenges, notably; only a single registration at a time can be >>> supported, the actual identity of the provider remains blind to the RP >>> until after the request is sent and it requires registration or some fo= rm >>> of default handling (e.g when there is no provider registered). >>> >>> *How GNAP can solve for this?* I actually don't think this is core to >>> GNAP, there may be some considerations around discovery that are worth >>> paying attention to but not much in the core protocol design. >>> >>> >>> SIOP doesn=E2=80=99t really solve the NASCAR issue since SIOP, by desig= n, >>> becomes yet one more login option among many. I think GNAP can help thi= s by >>> enabling user-directed provider discovery to kick off the process, but = I >>> agree that the core protocol doesn=E2=80=99t really have much to say he= re, and >>> shouldn=E2=80=99t. >>> >>> *Exploring different deployment models for the provider* - This is the >>> most frequently talked about aspect of SIOP and perhaps the most >>> interesting to GNAP. I like to think about the scope of this issue as >>> designing to allow for either a partially or fully >>> distributed/decentralized provider, rather than a centralized one (e.g = an >>> HTTP based AuthZ server). As you noted this does come with its challeng= es >>> many of which are technical in nature, i.e how to appropriately address= a >>> decentralized provider and what protocols are used to communicate with = the >>> provider. >>> >>> *How GNAP can solve for this?* I think that's what much of the >>> discussion on this thread will be about and whether there is a hybrid m= odel >>> where some responsibility is still centrally administered like token >>> issuance, while allowing other aspects to occur in a more distributed >>> manner. Ideally though I'd like to see consideration for a completely >>> distributed model too. >>> >>> >>> I agree that this seems to be the most interesting place for overlap. I >>> don=E2=80=99t actually think the =E2=80=9Chybrid=E2=80=9D approach cent= ralizes things. Instead, you >>> can think of the RS as having an associated AS, and that AS accepting u= ser >>> consent and claims at runtime from a variety of sources (wallets, VCs, >>> etc.). In this way, we aren=E2=80=99t talking about a single AS in the = world >>> handling all of these requests, we=E2=80=99re talking about a distribut= ed network >>> of AS=E2=80=99s associated with an even more widely distributed set of = RS=E2=80=99s. SSI >>> and its associated technologies would help these =E2=80=9Clocal=E2=80= =9D AS=E2=80=99s issue access >>> tokens without the RO needing to have an account, or even necessarily >>> directly interacting with the AS. There=E2=80=99s currently a technolog= y gap there, >>> but my thoughts are that this is where the changes to the interaction m= odes >>> section can really come to play. >>> >>> I think the notion of a non-HTTP AS is interesting, but I=E2=80=99m not= sure if >>> that=E2=80=99s something GNAP ought to be solving for. I think that the= re=E2=80=99s a deep >>> value in building on top of HTTP for the core protocol, and not abstrac= ting >>> away concepts from it. Otherwise, you end up re-inventing layers, and y= ou >>> get something like SOAP all over again. :) >>> >>> =E2=80=94 Justin >>> >>> >>> Thanks, >>> [image: Mattr website] >>> *Tobias Looker* >>> Mattr >>> +64 (0) 27 378 0461 >>> tobias.looker@mattr.global >>> [image: Mattr website] [image: Mattr on >>> LinkedIn] [image: Mattr >>> on Twitter] [image: Mattr on Github] >>> >>> This communication, including any attachments, is confidential. If you >>> are not the intended recipient, you should not read it - please contact= me >>> immediately, destroy it, and do not copy or use any part of this >>> communication or disclose anything about it. Thank you. Please note tha= t >>> this communication does not designate an information system for the >>> purposes of the Electronic Transactions Act 2002. >>> >>> >>> On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault >>> wrote: >>> >>>> Hi Justin, >>>> >>>> I agree that defining AS role primarily as a token issuer is a fruitfu= l >>>> idea. Solving this problem well would also respond to the challenges >>>> discussed previously on the list. >>>> >>>> Cheers >>>> Fabien >>>> >>>> >>>> Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer a >>>> =C3=A9crit : >>>> >>>>> The last interim call had a lot of discussion on SSI technologies suc= h >>>>> as digital wallets, and how those fit with GNAP. I think it=E2=80=99s= worth >>>>> continuing that conversation here on the list. There are a few issues= in >>>>> the tracker that give some background, too: >>>>> >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 >>>>> >>>>> There=E2=80=99s been a lot of interesting work recently in the OpenID >>>>> Foundation around using the Self-issued OP (SIOP) functionality to >>>>> bootstrap an SSI style login. This makes extensive use of the implici= t flow >>>>> and front channel messaging, but minimization of the front channel fo= r >>>>> message passing is a key design tenet of GNAP (so much so that it=E2= =80=99s >>>>> included in our charter). Instead, GNAP has been built around an idea= that >>>>> everything starts the same way: with an HTTP request to the AS. >>>>> >>>>> The idea of an on-device AS has been brought up a lot, and we need to >>>>> consider if and how we want to deal with these kinds of use cases. Th= e most >>>>> obvious way to address these would be to do some kind of clever off-H= TTP >>>>> hack like SIOP, but keep in mind that even SIOP generally starts off = with >>>>> an HTTP-based discovery call by the RP to make things work. >>>>> >>>>> My personal stance is that to do this, we need to re-evaluate our >>>>> assumptions about exactly what an AS does and what it needs to do tho= se >>>>> things. In OAuth 2, it=E2=80=99s assumed that the AS is the device th= at=E2=80=99s >>>>> authenticating the user, collecting consent, managing the client=E2= =80=99s >>>>> registration, and creating an access token based on whatever set of r= ights >>>>> that are associated with all of those things. In UMA, this is turned = around >>>>> a bit by letting the RO present a bunch of nebulous =E2=80=9Cclaims= =E2=80=9D interactively, >>>>> but still at the AS. >>>>> >>>>> With both of these, a key aspect remains: the AS needs to gather >>>>> necessary information, and issue the access token (or >>>>> identifiers/assertions). Because of how the protocol works, the clien= t >>>>> software now has a better opportunity to present information to the A= S, >>>>> either directly in the request or by introducing the AS to another so= ftware >>>>> component during the =E2=80=9Cinteraction=E2=80=9D phase. So, what if= we think of the AS >>>>> primarily as a =E2=80=9Ctoken issuer=E2=80=9D? >>>>> >>>>> For example, if the client can present a verifiable credential (VC) >>>>> that represents the end user, the AS can validate that VC and make an >>>>> access token on behalf of that user, without having the user log in o= r >>>>> interact with the AS at all. This VC can contain whatever access righ= ts the >>>>> token needs to represent, and the AS can translate that into an artif= act >>>>> that the downstream RS=E2=80=99s can interpret, without having to see= the original >>>>> VC or the user at all. The AS is still HTTP based, but all the essent= ial >>>>> security and rights elements are provided by the wallet. In this way,= we >>>>> can expand on the privacy-preserving aspects of OAuth and bridge the = worlds >>>>> of SSI and web APIs without violating the basic nature of either. >>>>> >>>>> Coming from the OAuth world, it feels weird to issue tokens like this= , >>>>> but there=E2=80=99s precedent for this kind of thing. Today, a there = are a number >>>>> of service-based OAuth AS's that are told what claims need to get put= into >>>>> the access token by some trusted component. All of this happens outsi= de the >>>>> OAuth protocol. In GNAP, I think it makes sense to account for this k= ind of >>>>> thing in how we define the protocol. That isn=E2=80=99t to say all of= these pieces >>>>> need to be defined in the core, but the base protocol ought to be abl= e to >>>>> handle being extended in this direction as needed. >>>>> >>>>> I=E2=80=99m really interested to hear other people=E2=80=99s thoughts= on how this >>>>> could come together. >>>>> >>>>> =E2=80=94 Justin >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >>> This communication, including any attachments, is confidential. If you = are not the intended recipient, you should not read it - please contact me = immediately, destroy it, and do not copy or use any part of this communicat= ion or disclose anything about it. Thank you. Please note that this communi= cation does not designate an information system for the purposes of the Ele= ctronic Transactions Act 2002. >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000595fc405bbbce204 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Fabien,

    I don't= disagree with the idea that GNAP should not presume the adoption of SSI st= andards or philosophy. (P. Sheldrake and I are pals and I'm an informal= channel between EFF and some SSI workgroups.)=C2=A0

    I do believe that RS and data brokers have a growing security problem th= at only Zero-Trust Architecture can do much to solve. Mobile wallets are es= sential=C2=A0to provide the non repudiable signatures (regardless of how cr= edentials are managed for privacy) and this will tend to facilitate some de= centralization even if it would not come naturally to the RS enterprise. Th= e SSI standards will apply to growing ZTA.

    ZTA can= not work=C2=A0just between wallet and RS. It needs delegation, notarization= , and audit. Therefore, I see GNAP as playing the central role.
    <= br>
    From this ZTA perspective, rather than privacy or decentraliz= ation as an abstract goal, the question of whether there are more or fewer = ASs than wallets is arguable. One guardian on the RO side or one "asso= ciate" on the RS side could easily each have as many AS as they have w= allets. Their ASs represent personas and semi-autonomous agents. Their mult= iple wallets represent redundant user agent devices each with a separate bi= ometrically locked HSM.=C2=A0

    In an enterprise (RS= or data broker) ZTA system, the delegation target may tend to look more li= ke an agent (AS) or client (RC) =C2=A0than like a wallet. For example, in h= ealthcare the guardians and associates control wallets and AS agents as the= target of delegation (workflow) while the enterprise electronic health rec= ord looks more like a client to various RSs. With ZTA, the RSs will be both= in and out of the control of the enterprise. I've summarized the relat= ionship between wallets, AS, RC, and RS as 6 use-cases in this short set of= slides:=C2=A0https://= docs.google.com/presentation/d/1ksKal62ZiApX09Nejm4RSqHzHJbgwpu_l2Ho64_ePKU= /edit#slide=3Did.gb2d2b0f28a_0_0=C2=A0

    I hope = this clarifies some expectations and where GNAP needs to align with other i= nitiatives.

    Adrian

    On Fri, Feb 19, 2021= at 9:03 PM Fabien Imbault <= fabien.imbault@gmail.com> wrote:
    Hi Adrian,=C2=A0

    "It's confusing to think that there are more RS tha= n AS" frames the problem we're dealing with.=C2=A0
    I think it really depends on how we view the auth world today and= in the future.=C2=A0

    Today there are many RSs providing spe= cialized APIs. Openbanking is an obvious example. So we're speaking the= order of magnitude of the number of organizational units for RSs, versus a= few centralized IdPs and ASs.
    Notice that if we can design GNAP in a=C2=A0 m= ore modular fashion than OAuth2 by enabling multiple ASs, that=C2=A0= would already be a fairly effective way to decentralize authorizations. Org= s are a well known target for privacy regulations, so we know what to expec= t, even if that's imperfect (of course bigtech regulation is still larg= ely an unsolved problem, but laws are gradually evolving).=C2=A0

    Now there's another view, which is : each person should be = operating its own AS and have its own wallet, as everyone has a phone.=C2= =A0
    While I believe P. Sheldrake offers a few hints = of why we should reflect on the social/ethical consequences of the technolo= gy (the generative vs self-sovereign identity debate, which I tried to summ= arize at https://fimbault.m= edium.com/the-ethical-dilemma-posed-by-decentralized-identity-f8328b655544<= /a>), it's quite clear that it is yet a prospective view. Wallets will = need to be "crossing the chiasm".=C2=A0






    Le ven. 19 f=C3= =A9vr. 2021 =C3=A0 23:50, Adrian Gropper <agropper@healthurl.com= > a =C3=A9crit=C2=A0:
    I agr= ee with the=C2=A0first=C2=A0two of Justin's responses but not the last = one.

    It's confusing to think that there are more RS = than AS. From a human-centered (and hopefully IETF) perspective, each perso= n might control or specify a different AS for each of their personas or for= each child or incompetent delegate of them as guardian. We're familiar= with separate gmail addresses for each persona.

    A= Ss will be self-sovereign (as in SSI), fiduciary (as in a custodial bitcoin= wallet), or brokers (as in data brokers and surveillance capitalism). Any = RS that is willing to have a recurring relationship with a persona could ac= cept a GNAP AS endpoint instead of an email address. This is easiest using = HTTP, but GNAP need not exclude other RS / AS APIs and transports. Designin= g around the uncensored specification=C2=A0of one's AS as a human right= would greatly simplify many aspects of GNAP adoption.

    =
    That said, GNAP should not ignore the RS business or jurisdictional=C2= =A0reasons to limit the authority of the AS. UMA 2.0 spent years dancing ar= ound this issue with ideas like "cascading" AS and various centra= lized or federated AS concepts. My conclusion is that any RS can always do = whatever it wants and there's not much the authorization protocol can h= elp with other than specifying a notification endpoint so that an RS can wa= rn (and seek confirmation) or log various exceptions. This turns out to be,= after a year of testimony, the regulation that applies to HIPAA RS APIs in= the US. For this reason GNAP might include a notification protocol in the = AS specification, or not.

    I propose that embracing= a self-sovereign agent is key to harmonizing the SSI and GNAP standards.

    Adrian

    On Fri, Feb 19, 2021 at 2:30 PM Justin = Richer <jricher@mit.edu> wrote:
    Tobias, t= hanks for the great observations. Some reactions inline below.

    =
    On Feb 18, 2021, at 7:59 PM, Tobias Looker &= lt;tobias.looker@mattr.global> wrote:

    Justin,

    I think this is a great and timely conve= rsation to be having given the current interest around SSI and efforts like= SIOP, I have been doing quite a bit of work in this space as of recent, so= thought I'd add a few of the observations that I've made.

    I= n my opinion SIOP was really a bucket for solving quite a few different pro= blems, not just one. In particular I think its intent was to solve 3 major = ones:

    1. Enabling portable identities
    2. Solving the NASCAR probl= em
    3. Exploring different deployment models for the provider

    To d= rill down briefly on these, note much of my terminology is OpenID based due= to SIOPs origin=C2=A0

    Enabling portable identities - In gene= ral today in the case of OpenID, the end-users identity as understood by a = relying party is scoped within the domain of the provider. Which means if t= hat provider goes out of business or for whatever reason decides to no long= er offer the same identity services to the End-User, their identity is esse= ntially gone. Whilst there has been some interesting related work from grou= ps like MODRNA on solutions to combat this like 'Account Porting', = they often assume the old provider remains online and willing to facilitate= in the account porting process so that the End-User can migrate to a new p= rovider. SIOP actually elected to do something different here by using cryp= tography, instead of the End-User identifier being something like a GUID as= serted within the domain of the provider, SIOP defined this instead as a pu= blic key fingerprint associated to a private key that's assumed to be u= nder the control of the user. In doing so the identity itself becomes porta= ble between providers by transferring the associated private key. Now this = approach does have drawbacks and arguably encourages what many would refer = to as bad cryptographic practise by not allowing any way to do key rotation= , however the idea was there.=C2=A0

    How GNAP can solv= e for this? By having flexibility around how the resource owner / End-U= ser is referred to by the Authorization server (e.g allow the identifier to= be something like a public key or a resolvable identifier to public keys s= uch as a DID)

    I perso= nally think that GNAP should be a flexible :carrier: of identifiers and oth= er bits of identity information. This is the main reason we went with the S= ubject Identifiers draft from SECEVENT: it=E2=80=99s set up to talk about a= variety of different kinds of identifiers, all of them asserted in the con= text of the AS. If there=E2=80=99s a definition for a DID URL or a JWK in t= he sub_ids object structure, GNAP would be able to just use it directly alo= ngside every other format. I haven=E2=80=99t seen those proposed yet, but i= t would be easy to do and, in my mind, would be a better solution than the = portable identifiers proposal that was recently brought up in the FAPI work= ing group in OIDF. (A side note, but the main problem I have here is that i= t=E2=80=99s pasting semantics and formats onto a field where none existed b= efore, and that=E2=80=99s rife for problems. Better to have a structure tha= t takes that into account from the start, in my view.)


    Solving the NASCAR problem= - One of those enduring problems in identity systems, which I think is= really about the three way negotiation going on between the RP, the End-Us= er and the Provider. SIOP's solution pushed for most of the power in th= is decision making process to lie with the End-User, letting them decide wh= o they want as their provider rather than RP's providing an enumeration= of who they support via provider icons on their login page and End-Users h= aving to select from those options. It accomplished this via using a custom= URL scheme of `openid://` where the E= nd-User would register their chosen provider as a protocol handler for the = `openid://` scheme. However, again as = a solution it's not without it's challenges, notably; only a single= registration at a time can be supported, the actual identity of the provid= er remains blind to the RP until after the request is sent and it requires = registration or some form of default handling (e.g when there is no provide= r registered).

    How GNAP can solve for this? I actually don= 9;t think this is core to GNAP, there may be some considerations around dis= covery that are worth paying attention to but not much in the core protocol= design.


    SIOP doe= sn=E2=80=99t really solve the NASCAR issue since SIOP, by design, becomes y= et one more login option among many. I think GNAP can help this by enabling= user-directed provider discovery to kick off the process, but I agree that= the core protocol doesn=E2=80=99t really have much to say here, and should= n=E2=80=99t.

    = Exploring different deployment models for the provider - This is the= most frequently talked about aspect of SIOP and perhaps the most interesti= ng to GNAP. I like to think about the scope of this issue as designing to a= llow for either a partially or fully distributed/decentralized provider, ra= ther than a centralized one (e.g an HTTP=C2=A0based AuthZ server). As you n= oted this does come with its challenges many of which are technical in natu= re, i.e how to appropriately address a decentralized provider and what prot= ocols are used to communicate with the provider.

    How GNAP can so= lve for this? I think that's=C2=A0what much of the discussion on th= is thread will be about and whether there is a hybrid model where some resp= onsibility is still centrally administered like token issuance, while allow= ing other aspects to occur in a more distributed manner. Ideally though I&#= 39;d like to see consideration for a completely distributed model too.

    I agree that this seems to be= the most interesting place for overlap. I don=E2=80=99t actually think the= =E2=80=9Chybrid=E2=80=9D approach centralizes things. Instead, you can thi= nk of the RS as having an associated AS, and that AS accepting user consent= and claims at runtime from a variety of sources (wallets, VCs, etc.). In t= his way, we aren=E2=80=99t talking about a single AS in the world handling = all of these requests, we=E2=80=99re talking about a distributed network of= AS=E2=80=99s associated with an even more widely distributed set of RS=E2= =80=99s. SSI and its associated technologies would help these =E2=80=9Cloca= l=E2=80=9D AS=E2=80=99s issue access tokens without the RO needing to have = an account, or even necessarily directly interacting with the AS. There=E2= =80=99s currently a technology gap there, but my thoughts are that this is = where the changes to the interaction modes section can really come to play.= =C2=A0

    I think the notion of a non-HTTP AS is inte= resting, but I=E2=80=99m not sure if that=E2=80=99s something GNAP ought to= be solving for. I think that there=E2=80=99s a deep value in building on t= op of HTTP for the core protocol, and not abstracting away concepts from it= . Otherwise, you end up re-inventing layers, and you get something like SOA= P all over again. :)

    =C2=A0=E2=80=94 Justin
    <= br>

    Thanks,
    3D"Mattr=C2=A0
    Tobias Looker
    =
    Mattr
    +64 (0) 27 378 0461
    tobias.looker@mattr.global
    3D"Mattr3D"Mattr3D"Mattr3D"Mat=This communication, including= any attachments, is confidential. If you are not the intended recipient, y= ou should not read it - please contact me immediately, destroy it, and do n= ot copy or use any part of this communication or disclose anything about it= . Thank you. Please note that this communication does not designate an info= rmation system for the purposes of the Electronic Transactions Act 2002.


    <= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 18, 2021 at 9:19 PM Fabien= Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justin,

    I agree that defining AS role primarily as a token issu= er is a fruitful idea. Solving this problem well would also respond to the = challenges discussed previously on the list.=C2=A0
    <= br>
    Cheers
    Fabien=C2=A0
    =

    Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:
    =
    The last interim call had a lot of discussion on SSI technologies such= as digital wallets, and how those fit with GNAP. I think it=E2=80=99s wort= h continuing that conversation here on the list. There are a few issues in = the tracker that give some background, too:


    There=E2= =80=99s been a lot of interesting work recently in the OpenID Foundation ar= ound using the Self-issued OP (SIOP) functionality to bootstrap an SSI styl= e login. This makes extensive use of the implicit flow and front channel me= ssaging, but minimization of the front channel for message passing is a key= design tenet of GNAP (so much so that it=E2=80=99s included in our charter= ). Instead, GNAP has been built around an idea that everything starts the s= ame way: with an HTTP request to the AS.=C2=A0

    The= idea of an on-device AS has been brought up a lot, and we need to consider= if and how we want to deal with these kinds of use cases. The most obvious= way to address these would be to do some kind of clever off-HTTP hack like= SIOP, but keep in mind that even SIOP generally starts off with an HTTP-ba= sed discovery call by the RP to make things work.

    = My personal stance is that to do this, we need to re-evaluate our assumptio= ns about exactly what an AS does and what it needs to do those things. In O= Auth 2, it=E2=80=99s assumed that the AS is the device that=E2=80=99s authe= nticating the user, collecting consent, managing the client=E2=80=99s regis= tration, and creating an access token based on whatever set of rights that = are associated with all of those things. In UMA, this is turned around a bi= t by letting the RO present a bunch of nebulous =E2=80=9Cclaims=E2=80=9D in= teractively, but still at the AS.=C2=A0

    With both = of these, a key aspect remains: the AS needs to gather necessary informatio= n, and issue the access token (or identifiers/assertions). Because of how t= he protocol works, the client software now has a better opportunity to pres= ent information to the AS, either directly in the request or by introducing= the AS to another software component during the =E2=80=9Cinteraction=E2=80= =9D phase. So, what if we think of the AS primarily as a =E2=80=9Ctoken iss= uer=E2=80=9D?=C2=A0

    For example, if the client can= present a verifiable credential (VC) that represents the end user, the AS = can validate that VC and make an access token on behalf of that user, witho= ut having the user log in or interact with the AS at all. This VC can conta= in whatever access rights the token needs to represent, and the AS can tran= slate that into an artifact that the downstream RS=E2=80=99s can interpret,= without having to see the original VC or the user at all. The AS is still = HTTP based, but all the essential security and rights elements are provided= by the wallet. In this way, we can expand on the privacy-preserving aspect= s of OAuth and bridge the worlds of SSI and web APIs without violating the = basic nature of either.

    Coming from the OAuth worl= d, it feels weird to issue tokens like this, but there=E2=80=99s precedent = for this kind of thing. Today, a there are a number of service-based OAuth = AS's that are told what claims need to get put into the access token by= some trusted component. All of this happens outside the OAuth protocol. In= GNAP, I think it makes sense to account for this kind of thing in how we d= efine the protocol. That isn=E2=80=99t to say all of these pieces need to b= e defined in the core, but the base protocol ought to be able to handle bei= ng extended in this direction as needed.

    I=E2=80= =99m really interested to hear other people=E2=80=99s thoughts on how this = could come together.

    =C2=A0=E2=80=94 Justin
    <= /div>
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000595fc405bbbce204-- From nobody Sun Feb 21 00:16:01 2021 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 C3B5F3A17FD for ; Sun, 21 Feb 2021 00:15:55 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=siuXBcP/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kYW90f+d 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 jC7NG2174BhS for ; Sun, 21 Feb 2021 00:15:53 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D859D3A0BBA for ; Sun, 21 Feb 2021 00:15:52 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AFB125C00DD for ; Sun, 21 Feb 2021 02:37:14 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 21 Feb 2021 02:37:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=C1BzoWs8Cox8uSqANGAF5Is624yL7aH3S7paeF4qLZ0=; b=siuXBcP/ 0wKFoqCoyP8ShcrtzZoEqA5zlNYLAlXcWkRlJjvNrDgMeoQFq7s4ELtPp9XjSN0z InYbp3ODloI8KjMHqt+7CyiKMYlQKGtQd3aLD8cpyh+gAFMw4JjTwvTKkM1G2bGn nykWNE/2XV4PMBDw2yoOdNABaAep5YF32Mfdipt6ZzmQ4lUO4imC0P5Xuh+PY913 uHgtwI8609vF2XOWQuQXUWWuIZuO97Gzy6BfREs7LcyJFR730++VcdIUM2f52MSO UUTTBh8rx/Fq+rua3xkDXdwVs30oSYZRQd4ivRpXH/wLGTcSDN+RR1nxY7rvNMEH ++8xHQbLOC13vg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=C1BzoWs8Cox8uSqANGAF5Is624yL7 aH3S7paeF4qLZ0=; b=kYW90f+duJ3SU3YymseMqUb+++rLXIHABE+wGSC1KR/jg zjJoXbE/M5iEfNp2elpc2joF3ubW9Nk8s0KjQRTmblY5wlcFPFptWN6KcCcuGZJY UtKjgPzsR/u18cYy2CZ1zhGYX6dvvJVQShcGqCuR+jx93CmjqJxR/NRelw9fGcvC auozfDNQthqL6nKr6XFq2YLwWnEUxED5JL+uB9WZhurMBDEIgdK8nimW5yDR29ZV dxZ937+Jlq5OCDtWEwbNCD7G/L2amlWfetjR/DVMj+ICBZYxaMPLotQ8b0AlybWP uxKwQhuKbEV41RM2lwmO0BOQuYeHbwsTlBTDu78gA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkedtgddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtthgvrh hnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudeiteen ucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrjeelrdekuddrudeije enucevlhhushhtvghrufhiiigvpeeinecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgp nhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az267-815.internal.cloudapp.net (unknown [40.79.81.167]) by mail.messagingengine.com (Postfix) with ESMTPA id 75E8E24005A for ; Sun, 21 Feb 2021 02:37:14 -0500 (EST) Content-Type: multipart/alternative; boundary="===============6338258388235004251==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210221073714.75E8E24005A@mailuser.nyi.internal> Date: Sun, 21 Feb 2021 02:37:14 -0500 (EST) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2021 08:15:56 -0000 --===============6338258388235004251== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-gnap/core-protocol (+12/-2/=F0=9F=92=AC34) 12 issues created: - Definition of a Subject in section 1.3 (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/198=20 - Requesting User Information (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/197=20 - Proving Possession of a Key with a Request for the AS and RS (by adeine= ga) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/196=20 - Requesting Resources With Insufficient Access (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/193=20 - The first figure in section 1.4 should be split and revisited (by Denis= themalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/192=20 - Validity of an access token (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/191=20 - Tentative proposal for a RS discovery mechanism (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/190=20 - Token format (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/189=20 - Prior relationship or not between a RS and an AS (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/188=20 - The case of a RS trusting more that one AS (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/187=20 - User consent and user notice (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/186=20 - Protected and Public Resources (by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/185=20 21 issues received 34 new comments: - #198 Definition of a Subject in section 1.3 (3 by Denisthemalice, fimba= ult) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/198=20 - #196 Proving Possession of a Key for the AS and RS (3 by adeinega, jric= her) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/196=20 - #192 The first figure in section 1.4 should be split and revisited (4 b= y Denisthemalice, agropper, fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/192=20 - #180 grant_request_endpoint, HTTPS and fragment component (3 by adeineg= a, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/180=20 - #178 sub_ids and different contexts (3 by fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/178=20 - #176 Protocol rationale (2 by fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/176=20 - #173 Rename DPoP digest parameter (2 by adeinega, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/173=20 - #171 subject identifiers as portable identifiers (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/171=20 - #169 token based delegation (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/169=20 - #168 message based interaction / DIDComm (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/168=20 - #166 Create JSON Schema (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/166=20 - #115 Token Introspection (1 by Denisthemalice) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115=20 - #99 Updating and reading access tokens (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/99 [Needs Tex= t]=20 - #98 Reading the state of a request (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/98 [Needs Tex= t]=20 - #75 Scope of subject identifiers (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/75=20 - #50 User identification items (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/50=20 - #49 AS Validation of RC-presented assertions (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/49=20 - #43 User information request items (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/43=20 - #42 Use of identifiers as communication channels (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/42=20 - #41 Assertion format names (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/41=20 - #16 "Bad" use of Subject Identifiers (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/16=20 2 issues closed: - Updating and reading access tokens https://github.com/ietf-wg-gnap/gnap= -core-protocol/issues/99 [Needs Text]=20 - Reading the state of a request https://github.com/ietf-wg-gnap/gnap-cor= e-protocol/issues/98 [Needs Text]=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+7/-5/=F0=9F=92=AC21) 7 pull requests submitted: - Adding information about the Cache-Control header and its value. (by ad= einega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/199=20 - Update DPoP Syntax (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/195=20 - Suggested changes for the field names (Discovery). (by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/194=20 - 178 sub_ids and different contexts (by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/184=20 - 180 Requirements for the location of grant_request_endpoint. (by adeine= ga) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/183=20 - Replace Content-type by Content-Type. (by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/182=20 - Fix the example of Attached JWS (by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/181=20 8 pull requests received 21 new comments: - #199 Adding information about the Cache-Control header and its value. (= 3 by adeinega, jricher, netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/199=20 - #195 Update DPoP Syntax (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/195=20 - #194 Suggested changes for Discovery field names (2 by jricher, netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/194=20 - #184 sub_ids and different contexts (8 by adeinega, fimbault, jricher, = netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/184=20 - #183 180 Requirements for the location of grant_request_endpoint. (1 by= netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/183=20 - #182 Replace Content-type by Content-Type. (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/182=20 - #181 Fix the example of Attached JWS (4 by adeinega, jricher, netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/181 [Editorial]= =20 - #164 initial attempt at grouping interaction modes (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/164=20 5 pull requests merged: - Replace Content-type by Content-Type. https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/182 [Editorial]= =20 - Fix the example of Attached JWS https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/181 [Editorial]= =20 - Fix typos. https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/179 [Editorial]= =20 - Fix subject identifier type hint https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/177 [Editorial]= =20 - closing issue 98, effectively removing section 5.4 https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/170 [Pending Me= rge]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============6338258388235004251== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (GNAP Weekly GitHub Activity Summary)

    Sunday February 21, 2021

    Events without label "editorial"

    Issues

    ietf-wg-gnap/core-protocol (+12/-2/=F0=9F=92=AC34)

    12 issues created:

    21 issues received 34 new comments:

    2 issues closed:

    Pull requests

    ietf-wg-gnap/core-protocol (+7/-5/=F0=9F=92=AC21)

    7 pull requests submitted:

    8 pull requests received 21 new comments:

    5 pull requests merged:

    Repositories tracked by this digest:

    --===============6338258388235004251==-- From nobody Sun Feb 21 01:34:27 2021 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 75C3E3A18A4 for ; Sun, 21 Feb 2021 01:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=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=lodderstedt.net 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 6y3J80xnxKum for ; Sun, 21 Feb 2021 01:34:21 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 CF99B3A0BDA for ; Sun, 21 Feb 2021 01:34:20 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id m1so11651868wml.2 for ; Sun, 21 Feb 2021 01:34:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=NlApa+E6LqIdqXyp7b1twuNoVmF3SEOX11Xiv2YQ3us=; b=f/Spw2SZxNa9eizCQFSxgYkGaiFveeBqULzj9aSQ8rzKfooar6I6f49JisQPTJeDGT 2SVzKMBbIc3NR9IZB7psDb7OsLZOCH1V50YSDJsX8JgpjJmKEkrh+slTm86Nyb6QNrWA ubKoRaB4rXNRN8Z1wXspDBZgxixL65QfQ93lwo3py6Or8nNDaC/5UExeJNl0iMPqRHff /f8idu6rRw/W2PojonlvgAXPaPbdJS26j7xN5Y7fcs9IwSpgl8m1SCWXzoN7Ch0XH9vF PoD7NanBXxXiHvlBW3NMRZrEllmMubPXLBFLySd1e/LMdJmzQYZnZ1JPqfHDfiSqYoR8 EhmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=NlApa+E6LqIdqXyp7b1twuNoVmF3SEOX11Xiv2YQ3us=; b=tRoJcTPdMCMVWx9bI4Qx6FAYSX+kOcRncBNyl9uqewMAwVNN40Bshd1jgLEbbo531A rquS1TIKdS5USkRv3VXfq2dUj7EjrR3aTRtpKmw2xZ4TDzUTBlGMoMRtV3kdyxwHCSWg U8tN8xGgrj/4UIZoxG0skYfgMwn7i5gYWkP7rNeWEgzYDxkD+fdOddrsW2Elp+jQts9N RvbJmmyfGVjz1vnxM/7xeZ42oKimbwvjkixodQ99PKa3Xsc3e2mm9vozU+kT9sVzQgZB 5dQZu14WWxFnJKgXkeeoJg2Q9AnIPkkW7yDwBxOmLKA5z7DKYhBlIgJ6SUzgZqgwg2za fiKw== X-Gm-Message-State: AOAM530EZOpQF6cMRyk5d0pnWg/bUGBN1XjefjWXLf/hVn+ok+25fmDs Y8uUUg9ibphKk7BLzHSJT3qHEQ== X-Google-Smtp-Source: ABdhPJx2DaRlnZ8dDCE6XAmd6/WLx+ym1TVlpGWw9CNN72jY4xHSHXL4ccaaFP7/U5AklO7lR5o+gw== X-Received: by 2002:a05:600c:3399:: with SMTP id o25mr15170025wmp.13.1613900059023; Sun, 21 Feb 2021 01:34:19 -0800 (PST) Received: from [192.168.71.135] (p5b0d975b.dip0.t-ipconnect.de. [91.13.151.91]) by smtp.gmail.com with ESMTPSA id k11sm23483151wrl.84.2021.02.21.01.34.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 21 Feb 2021 01:34:18 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-3624BD70-AD67-41BF-AB0D-E19D0F3F7BB5; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sun, 21 Feb 2021 10:34:16 +0100 Message-Id: References: Cc: Justin Richer , Fabien Imbault , txauth gnap , Tobias Looker In-Reply-To: To: Adrian Gropper X-Mailer: iPad Mail (18D52) Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2021 09:34:26 -0000 --Apple-Mail-3624BD70-AD67-41BF-AB0D-E19D0F3F7BB5 Content-Type: multipart/alternative; boundary=Apple-Mail-F5F304CA-3796-4F63-AC42-B349AF5A5E08 Content-Transfer-Encoding: 7bit --Apple-Mail-F5F304CA-3796-4F63-AC42-B349AF5A5E08 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 19.02.2021 um 23:50 schrieb Adrian Gropper : >=20 > =EF=BB=BF > I agree with the first two of Justin's responses but not the last one. >=20 > It's confusing to think that there are more RS than AS. the OAuth deployments I=E2=80=98m aware of typically have much more RSs than= ASs. Why? Because AS and a set of RSs belong to the same security domain (e= .g. a certain business) and it=E2=80=99s the AS=E2=80=99s responsibility to e= nsure secure and convenient access to the APIs provided by this RSs. For exa= mple: there is a AS controlling access to a cloud, streaming, and messaging s= ervices of the same business. In case of open banking, the bank=E2=80=98s AS= is (on behalf of the user) authorizing access to APIs for account informati= on as well as payment initiation and potentially other services.=20 Technically, the respective AS and RSs set up a trust relationship and agree= d on ways to share authorization and user data in order enable secure API ac= cess. I read your ideas regarding self-sovereign ASs with great interest and got s= ome observations/questions: - A personal AS could certainly control access to a person=E2=80=98s resourc= es. I assume the person=E2=80=98s RSs would only accept access tokens signed= by the RO. Am I right? - Do you envision this AS to be able to control access to any kind of RS? Ho= w is the AS supposed to know what authorization data this RS needs in order t= o perform access control decisions? What data will be exchanged? - How would this person delegate access to her resources to someone else? - Are you aware of deployments implementing this philosophy? - What are the implications in terms of user experience? In my experience coupling between AS and RS is very tight. I have a hard tim= e to see how self-sovereign ASs would work. It feels like such an AS in the e= nd is an identity provider of some sort, which brings me to what Justin prop= osed. I would assume using SSI credentials to authenticate towards ASs is fe= asible and might have value but I=E2=80=98m skeptical about the AS part. best regards, Torsten. > =46rom a human-centered (and hopefully IETF) perspective, each person migh= t control or specify a different AS for each of their personas or for each c= hild or incompetent delegate of them as guardian. We're familiar with separa= te gmail addresses for each persona. >=20 > ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial bitco= in wallet), or brokers (as in data brokers and surveillance capitalism). Any= RS that is willing to have a recurring relationship with a persona could ac= cept a GNAP AS endpoint instead of an email address. This is easiest using H= TTP, but GNAP need not exclude other RS / AS APIs and transports. Designing a= round the uncensored specification of one's AS as a human right would greatl= y simplify many aspects of GNAP adoption. >=20 > That said, GNAP should not ignore the RS business or jurisdictional reason= s to limit the authority of the AS. UMA 2.0 spent years dancing around this i= ssue with ideas like "cascading" AS and various centralized or federated AS c= oncepts. My conclusion is that any RS can always do whatever it wants and th= ere's not much the authorization protocol can help with other than specifyin= g a notification endpoint so that an RS can warn (and seek confirmation) or l= og various exceptions. This turns out to be, after a year of testimony, the r= egulation that applies to HIPAA RS APIs in the US. For this reason GNAP migh= t include a notification protocol in the AS specification, or not. >=20 > I propose that embracing a self-sovereign agent is key to harmonizing the S= SI and GNAP standards. >=20 > Adrian >=20 >> On Fri, Feb 19, 2021 at 2:30 PM Justin Richer wrote: >> Tobias, thanks for the great observations. Some reactions inline below. >>=20 >>>> On Feb 18, 2021, at 7:59 PM, Tobias Looker = wrote: >>>>=20 >>>> Justin, >>>>=20 >>>> I think this is a great and timely conversation to be having given the c= urrent interest around SSI and efforts like SIOP, I have been doing quite a b= it of work in this space as of recent, so thought I'd add a few of the obser= vations that I've made. >>>>=20 >>>> In my opinion SIOP was really a bucket for solving quite a few differen= t problems, not just one. In particular I think its intent was to solve 3 ma= jor ones: >>>>=20 >>>> 1. Enabling portable identities >>>> 2. Solving the NASCAR problem >>>> 3. Exploring different deployment models for the provider >>>>=20 >>>> To drill down briefly on these, note much of my terminology is OpenID b= ased due to SIOPs origin=20 >>>>=20 >>>> Enabling portable identities - In general today in the case of OpenID, t= he end-users identity as understood by a relying party is scoped within the d= omain of the provider. Which means if that provider goes out of business or f= or whatever reason decides to no longer offer the same identity services to t= he End-User, their identity is essentially gone. Whilst there has been some i= nteresting related work from groups like MODRNA on solutions to combat this l= ike 'Account Porting', they often assume the old provider remains online and= willing to facilitate in the account porting process so that the End-User c= an migrate to a new provider. SIOP actually elected to do something differen= t here by using cryptography, instead of the End-User identifier being somet= hing like a GUID asserted within the domain of the provider, SIOP defined th= is instead as a public key fingerprint associated to a private key that's as= sumed to be under the control of the user. In doing so the identity itself b= ecomes portable between providers by transferring the associated private key= . Now this approach does have drawbacks and arguably encourages what many wo= uld refer to as bad cryptographic practise by not allowing any way to do key= rotation, however the idea was there.=20 >>>>=20 >>>> How GNAP can solve for this? By having flexibility around how the resou= rce owner / End-User is referred to by the Authorization server (e.g allow t= he identifier to be something like a public key or a resolvable identifier t= o public keys such as a DID) >>>=20 >>> I personally think that GNAP should be a flexible :carrier: of identifie= rs and other bits of identity information. This is the main reason we went w= ith the Subject Identifiers draft from SECEVENT: it=E2=80=99s set up to talk= about a variety of different kinds of identifiers, all of them asserted in t= he context of the AS. If there=E2=80=99s a definition for a DID URL or a JWK= in the sub_ids object structure, GNAP would be able to just use it directly= alongside every other format. I haven=E2=80=99t seen those proposed yet, bu= t it would be easy to do and, in my mind, would be a better solution than th= e portable identifiers proposal that was recently brought up in the FAPI wor= king group in OIDF. (A side note, but the main problem I have here is that i= t=E2=80=99s pasting semantics and formats onto a field where none existed be= fore, and that=E2=80=99s rife for problems. Better to have a structure that t= akes that into account from the start, in my view.) >>>=20 >>>=20 >>> Solving the NASCAR problem - One of those enduring problems in identity s= ystems, which I think is really about the three way negotiation going on bet= ween the RP, the End-User and the Provider. SIOP's solution pushed for most o= f the power in this decision making process to lie with the End-User, lettin= g them decide who they want as their provider rather than RP's providing an e= numeration of who they support via provider icons on their login page and En= d-Users having to select from those options. It accomplished this via using a= custom URL scheme of `openid://` where the End-User would register their ch= osen provider as a protocol handler for the `openid://` scheme. However, aga= in as a solution it's not without it's challenges, notably; only a single re= gistration at a time can be supported, the actual identity of the provider r= emains blind to the RP until after the request is sent and it requires regis= tration or some form of default handling (e.g when there is no provider regi= stered). >>>=20 >>> How GNAP can solve for this? I actually don't think this is core to GNAP= , there may be some considerations around discovery that are worth paying at= tention to but not much in the core protocol design. >>>=20 >>=20 >> SIOP doesn=E2=80=99t really solve the NASCAR issue since SIOP, by design,= becomes yet one more login option among many. I think GNAP can help this by= enabling user-directed provider discovery to kick off the process, but I ag= ree that the core protocol doesn=E2=80=99t really have much to say here, and= shouldn=E2=80=99t. >>=20 >>> Exploring different deployment models for the provider - This is the mos= t frequently talked about aspect of SIOP and perhaps the most interesting to= GNAP. I like to think about the scope of this issue as designing to allow f= or either a partially or fully distributed/decentralized provider, rather th= an a centralized one (e.g an HTTP based AuthZ server). As you noted this doe= s come with its challenges many of which are technical in nature, i.e how to= appropriately address a decentralized provider and what protocols are used t= o communicate with the provider.=20 >>>=20 >>> How GNAP can solve for this? I think that's what much of the discussion o= n this thread will be about and whether there is a hybrid model where some r= esponsibility is still centrally administered like token issuance, while all= owing other aspects to occur in a more distributed manner. Ideally though I'= d like to see consideration for a completely distributed model too. >>=20 >> I agree that this seems to be the most interesting place for overlap. I d= on=E2=80=99t actually think the =E2=80=9Chybrid=E2=80=9D approach centralize= s things. Instead, you can think of the RS as having an associated AS, and t= hat AS accepting user consent and claims at runtime from a variety of source= s (wallets, VCs, etc.). In this way, we aren=E2=80=99t talking about a singl= e AS in the world handling all of these requests, we=E2=80=99re talking abou= t a distributed network of AS=E2=80=99s associated with an even more widely d= istributed set of RS=E2=80=99s. SSI and its associated technologies would he= lp these =E2=80=9Clocal=E2=80=9D AS=E2=80=99s issue access tokens without th= e RO needing to have an account, or even necessarily directly interacting wi= th the AS. There=E2=80=99s currently a technology gap there, but my thoughts= are that this is where the changes to the interaction modes section can rea= lly come to play.=20 >>=20 >> I think the notion of a non-HTTP AS is interesting, but I=E2=80=99m not s= ure if that=E2=80=99s something GNAP ought to be solving for. I think that t= here=E2=80=99s a deep value in building on top of HTTP for the core protocol= , and not abstracting away concepts from it. Otherwise, you end up re-invent= ing layers, and you get something like SOAP all over again. :) >>=20 >> =E2=80=94 Justin >>=20 >>>=20 >>> Thanks, >>> =09 >>> Tobias Looker >>> Mattr >>> +64 (0) 27 378 0461 >>> tobias.looker@mattr.global >>> =09 >>>=20 >>> This communication, including any attachments, is confidential. If you a= re not the intended recipient, you should not read it - please contact me im= mediately, destroy it, and do not copy or use any part of this communication= or disclose anything about it. Thank you. Please note that this communicati= on does not designate an information system for the purposes of the Electron= ic Transactions Act 2002. >>>=20 >>>=20 >>>> On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault wrote: >>>> Hi Justin, >>>>=20 >>>> I agree that defining AS role primarily as a token issuer is a fruitful= idea. Solving this problem well would also respond to the challenges discus= sed previously on the list.=20 >>>>=20 >>>> Cheers >>>> Fabien=20 >>>>=20 >>>>=20 >>>>> Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer a =C3=A9crit : >>>>> The last interim call had a lot of discussion on SSI technologies such= as digital wallets, and how those fit with GNAP. I think it=E2=80=99s worth= continuing that conversation here on the list. There are a few issues in th= e tracker that give some background, too: >>>>>=20 >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 >>>>>=20 >>>>> There=E2=80=99s been a lot of interesting work recently in the OpenID = Foundation around using the Self-issued OP (SIOP) functionality to bootstrap= an SSI style login. This makes extensive use of the implicit flow and front= channel messaging, but minimization of the front channel for message passin= g is a key design tenet of GNAP (so much so that it=E2=80=99s included in ou= r charter). Instead, GNAP has been built around an idea that everything star= ts the same way: with an HTTP request to the AS.=20 >>>>>=20 >>>>> The idea of an on-device AS has been brought up a lot, and we need to c= onsider if and how we want to deal with these kinds of use cases. The most o= bvious way to address these would be to do some kind of clever off-HTTP hack= like SIOP, but keep in mind that even SIOP generally starts off with an HTT= P-based discovery call by the RP to make things work. >>>>>=20 >>>>> My personal stance is that to do this, we need to re-evaluate our assu= mptions about exactly what an AS does and what it needs to do those things. I= n OAuth 2, it=E2=80=99s assumed that the AS is the device that=E2=80=99s aut= henticating the user, collecting consent, managing the client=E2=80=99s regi= stration, and creating an access token based on whatever set of rights that a= re associated with all of those things. In UMA, this is turned around a bit b= y letting the RO present a bunch of nebulous =E2=80=9Cclaims=E2=80=9D intera= ctively, but still at the AS.=20 >>>>>=20 >>>>> With both of these, a key aspect remains: the AS needs to gather neces= sary information, and issue the access token (or identifiers/assertions). Be= cause of how the protocol works, the client software now has a better opport= unity to present information to the AS, either directly in the request or by= introducing the AS to another software component during the =E2=80=9Cintera= ction=E2=80=9D phase. So, what if we think of the AS primarily as a =E2=80=9C= token issuer=E2=80=9D?=20 >>>>>=20 >>>>> For example, if the client can present a verifiable credential (VC) th= at represents the end user, the AS can validate that VC and make an access t= oken on behalf of that user, without having the user log in or interact with= the AS at all. This VC can contain whatever access rights the token needs t= o represent, and the AS can translate that into an artifact that the downstr= eam RS=E2=80=99s can interpret, without having to see the original VC or the= user at all. The AS is still HTTP based, but all the essential security and= rights elements are provided by the wallet. In this way, we can expand on t= he privacy-preserving aspects of OAuth and bridge the worlds of SSI and web A= PIs without violating the basic nature of either. >>>>>=20 >>>>> Coming from the OAuth world, it feels weird to issue tokens like this,= but there=E2=80=99s precedent for this kind of thing. Today, a there are a n= umber of service-based OAuth AS's that are told what claims need to get put i= nto the access token by some trusted component. All of this happens outside t= he OAuth protocol. In GNAP, I think it makes sense to account for this kind o= f thing in how we define the protocol. That isn=E2=80=99t to say all of thes= e pieces need to be defined in the core, but the base protocol ought to be a= ble to handle being extended in this direction as needed. >>>>>=20 >>>>> I=E2=80=99m really interested to hear other people=E2=80=99s thoughts o= n how this could come together. >>>>>=20 >>>>> =E2=80=94 Justin >>>>> --=20 >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>=20 >>> This communication, including any attachments, is confidential. If you a= re not the intended recipient, you should not read it - please contact me im= mediately, destroy it, and do not copy or use any part of this communication= or disclose anything about it. Thank you. Please note that this communicati= on does not designate an information system for the purposes of the Electron= ic Transactions Act 2002. >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txaut= h&source=3Dgmail-imap&ust=3D1614379828000000&usg=3DAOvVaw3avsUGQ48fo1OUQV0vy= yKd --Apple-Mail-F5F304CA-3796-4F63-AC42-B349AF5A5E08 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


    Am 19.02.2021 um 23:50 schrieb Adrian Gropper= <agropper@healthurl.com>:

    =EF=BB=BF
    I agree with the firs= t two of Justin's responses but not the last one.

    It= 's confusing to think that there are more RS than AS.

    the OAuth deployments I=E2=80=98m aware of typic= ally have much more RSs than ASs. Why? Because AS and a set of RSs belong to= the same security domain (e.g. a certain business) and it=E2=80=99s the AS=E2= =80=99s responsibility to ensure secure and convenient access to the APIs pr= ovided by this RSs. For example: there is a AS controlling access to a cloud= , streaming, and messaging services of the same business. In case of open ba= nking, the bank=E2=80=98s AS is (on behalf of the user) authorizing access t= o APIs for account information as well as payment initiation and potentially= other services. 

    Technically, the respective A= S and RSs set up a trust relationship and agreed on ways to share authorizat= ion and user data in order enable secure API access.

    I read your ideas regarding self-sovereign ASs with great interest and got= some observations/questions:
    - A personal AS could certainly cont= rol access to a person=E2=80=98s resources. I assume the person=E2=80=98s RS= s would only accept access tokens signed by the RO. Am I right?
    - D= o you envision this AS to be able to control access to any kind of RS? How i= s the AS supposed to know what authorization data this RS needs in order to p= erform access control decisions? What data will be exchanged?
    - Ho= w would this person delegate access to her resources to someone else?
    <= div>- Are you aware of deployments implementing this philosophy?
    -= What are the implications in terms of user experience?

    =
    In my experience coupling between AS and RS is very tight. I have a har= d time to see how self-sovereign ASs would work. It feels like such an AS in= the end is an identity provider of some sort, which brings me to what Justi= n proposed. I would assume using SSI credentials to authenticate towards ASs= is feasible and might have value but I=E2=80=98m skeptical about the AS par= t.

    best regards,
    Torsten.

    =46rom a human-c= entered (and hopefully IETF) perspective, each person might control or speci= fy a different AS for each of their personas or for each child or incompeten= t delegate of them as guardian. We're familiar with separate gmail addresses= for each persona.

    ASs will be self-sovereign (as i= n SSI), fiduciary (as in a custodial bitcoin wallet), or brokers (as in data= brokers and surveillance capitalism). Any RS that is willing to have a recu= rring relationship with a persona could accept a GNAP AS endpoint instead of= an email address. This is easiest using HTTP, but GNAP need not exclude oth= er RS / AS APIs and transports. Designing around the uncensored specificatio= n of one's AS as a human right would greatly simplify many aspects of G= NAP adoption.

    That said, GNAP should not ignore the= RS business or jurisdictional reasons to limit the authority of the AS= . UMA 2.0 spent years dancing around this issue with ideas like "cascading" A= S and various centralized or federated AS concepts. My conclusion is that an= y RS can always do whatever it wants and there's not much the authorization p= rotocol can help with other than specifying a notification endpoint so that a= n RS can warn (and seek confirmation) or log various exceptions. This turns o= ut to be, after a year of testimony, the regulation that applies to HIPAA RS= APIs in the US. For this reason GNAP might include a notification protocol i= n the AS specification, or not.

    I propose that embr= acing a self-sovereign agent is key to harmonizing the SSI and GNAP standard= s.

    Adrian

    On Fri, Feb 19, 2021 at 2:30 PM Justi= n Richer <jricher@mit.edu> wrot= e:
    Tobias, thanks for the great observations. Some reactions in= line below.

    On Feb 18, 2021, at 7= :59 PM, Tobias Looker <tobias.looker@mattr.global> wrote:

    Justin,

    I think this is a great and timely conversation to= be having given the current interest around SSI and efforts like SIOP, I ha= ve been doing quite a bit of work in this space as of recent, so thought I'd= add a few of the observations that I've made.

    In my opinion SIOP was= really a bucket for solving quite a few different problems, not just one. I= n particular I think its intent was to solve 3 major ones:

    1. Enablin= g portable identities
    2. Solving the NASCAR problem
    3. Exploring diffe= rent deployment models for the provider

    To drill down briefly on thes= e, note much of my terminology is OpenID based due to SIOPs origin 
    =
    Enabling portable identities - In general today in the case of Op= enID, the end-users identity as understood by a relying party is scoped with= in the domain of the provider. Which means if that provider goes out of busi= ness or for whatever reason decides to no longer offer the same identity ser= vices to the End-User, their identity is essentially gone. Whilst there has b= een some interesting related work from groups like MODRNA on solutions to co= mbat this like 'Account Porting', they often assume the old provider remains= online and willing to facilitate in the account porting process so that the= End-User can migrate to a new provider. SIOP actually elected to do somethi= ng different here by using cryptography, instead of the End-User identifier b= eing something like a GUID asserted within the domain of the provider, SIOP d= efined this instead as a public key fingerprint associated to a private key t= hat's assumed to be under the control of the user. In doing so the identity i= tself becomes portable between providers by transferring the associated priv= ate key. Now this approach does have drawbacks and arguably encourages what m= any would refer to as bad cryptographic practise by not allowing any way to d= o key rotation, however the idea was there. 

    How G= NAP can solve for this? By having flexibility around how the resource ow= ner / End-User is referred to by the Authorization server (e.g allow the ide= ntifier to be something like a public key or a resolvable identifier to publ= ic keys such as a DID)

    I personally think that GNAP should be a flexible :carrier: of identifiers a= nd other bits of identity information. This is the main reason we went with t= he Subject Identifiers draft from SECEVENT: it=E2=80=99s set up to talk abou= t a variety of different kinds of identifiers, all of them asserted in the c= ontext of the AS. If there=E2=80=99s a definition for a DID URL or a JWK in t= he sub_ids object structure, GNAP would be able to just use it directly alon= gside every other format. I haven=E2=80=99t seen those proposed yet, but it w= ould be easy to do and, in my mind, would be a better solution than the port= able identifiers proposal that was recently brought up in the FAPI working g= roup in OIDF. (A side note, but the main problem I have here is that it=E2=80= =99s pasting semantics and formats onto a field where none existed before, a= nd that=E2=80=99s rife for problems. Better to have a structure that takes t= hat into account from the start, in my view.)


    Solving the NASCAR problem - One o= f those enduring problems in identity systems, which I think is really about= the three way negotiation going on between the RP, the End-User and the Pro= vider. SIOP's solution pushed for most of the power in this decision making p= rocess to lie with the End-User, letting them decide who they want as their p= rovider rather than RP's providing an enumeration of who they support via pr= ovider icons on their login page and End-Users having to select from those o= ptions. It accomplished this via using a custom URL scheme of `openid://`= where the End-User would register their chosen provider as a protocol h= andler for the `openid://` scheme. However, again as a solution it's n= ot without it's challenges, notably; only a single registration at a time ca= n be supported, the actual identity of the provider remains blind to the RP u= ntil after the request is sent and it requires registration or some form of d= efault handling (e.g when there is no provider registered).

    How GN= AP can solve for this? I actually don't think this is core to GNAP, ther= e may be some considerations around discovery that are worth paying attentio= n to but not much in the core protocol design.


    SIOP doesn=E2=80=99t really solve the NASCAR is= sue since SIOP, by design, becomes yet one more login option among many. I t= hink GNAP can help this by enabling user-directed provider discovery to kick= off the process, but I agree that the core protocol doesn=E2=80=99t really h= ave much to say here, and shouldn=E2=80=99t.

    Exploring different deployment models for t= he provider - This is the most frequently talked about aspect of SIOP an= d perhaps the most interesting to GNAP. I like to think about the scope of t= his issue as designing to allow for either a partially or fully distributed/= decentralized provider, rather than a centralized one (e.g an HTTP base= d AuthZ server). As you noted this does come with its challenges many of whi= ch are technical in nature, i.e how to appropriately address a decentralized= provider and what protocols are used to communicate with the provider.
    =
    How GNAP can solve for this? I think that's what much of the= discussion on this thread will be about and whether there is a hybrid model= where some responsibility is still centrally administered like token issuan= ce, while allowing other aspects to occur in a more distributed manner. Idea= lly though I'd like to see consideration for a completely distributed model t= oo.

    I agree that this seem= s to be the most interesting place for overlap. I don=E2=80=99t actually thi= nk the =E2=80=9Chybrid=E2=80=9D approach centralizes things. Instead, you ca= n think of the RS as having an associated AS, and that AS accepting user con= sent and claims at runtime from a variety of sources (wallets, VCs, etc.). I= n this way, we aren=E2=80=99t talking about a single AS in the world handlin= g all of these requests, we=E2=80=99re talking about a distributed network o= f AS=E2=80=99s associated with an even more widely distributed set of RS=E2=80= =99s. SSI and its associated technologies would help these =E2=80=9Clocal=E2= =80=9D AS=E2=80=99s issue access tokens without the RO needing to have an ac= count, or even necessarily directly interacting with the AS. There=E2=80=99s= currently a technology gap there, but my thoughts are that this is where th= e changes to the interaction modes section can really come to play. 

    I think the notion of a non-HTTP AS is interesting, b= ut I=E2=80=99m not sure if that=E2=80=99s something GNAP ought to be solving= for. I think that there=E2=80=99s a deep value in building on top of HTTP f= or the core protocol, and not abstracting away concepts from it. Otherwise, y= ou end up re-inventing layers, and you get something like SOAP all over agai= n. :)

     =E2=80=94 Justin


    Thanks,
    3D"Ma= 
    Tobias Looker
    Mattr
    +64 (0) 27 378 0461
    tobias.looker@mattr.global
    <= td width=3D"40">3D"Mattr
    3D"Mattr3D"Mattr3D"Mattr
    <= /td>

    This communication, including any attachments, is confidential. If= you are not the intended recipient, you should not read it - please contact= me immediately, destroy it, and do not copy or use any part of this communi= cation or disclose anything about it. Thank you. Please note that this commu= nication does not designate an information system for the purposes of the El= ectronic Transactions Act 2002.


    On Thu= , Feb 18, 2021 at 9:19 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justin,

    <= div dir=3D"auto">I agree that defining AS role primarily as a token issuer i= s a fruitful idea. Solving this problem well would also respond to the chall= enges discussed previously on the list. 

    Cheers
    Fabien 

    Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer <jricher@mit.edu> a =C3=A9crit&= nbsp;:
    The last interim call had a lot of discu= ssion on SSI technologies such as digital wallets, and how those fit with GN= AP. I think it=E2=80=99s worth continuing that conversation here on the list= . There are a few issues in the tracker that give some background, too:
    =

    There=E2=80=99s been a lot of interesti= ng work recently in the OpenID Foundation around using the Self-issued OP (S= IOP) functionality to bootstrap an SSI style login. This makes extensive use= of the implicit flow and front channel messaging, but minimization of the f= ront channel for message passing is a key design tenet of GNAP (so much so t= hat it=E2=80=99s included in our charter). Instead, GNAP has been built arou= nd an idea that everything starts the same way: with an HTTP request to the A= S. 

    The idea of an on-device AS has been broug= ht up a lot, and we need to consider if and how we want to deal with these k= inds of use cases. The most obvious way to address these would be to do some= kind of clever off-HTTP hack like SIOP, but keep in mind that even SIOP gen= erally starts off with an HTTP-based discovery call by the RP to make things= work.

    My personal stance is that to do this, we ne= ed to re-evaluate our assumptions about exactly what an AS does and what it n= eeds to do those things. In OAuth 2, it=E2=80=99s assumed that the AS is the= device that=E2=80=99s authenticating the user, collecting consent, managing= the client=E2=80=99s registration, and creating an access token based on wh= atever set of rights that are associated with all of those things. In UMA, t= his is turned around a bit by letting the RO present a bunch of nebulous =E2= =80=9Cclaims=E2=80=9D interactively, but still at the AS. 
    With both of these, a key aspect remains: the AS needs to gathe= r necessary information, and issue the access token (or identifiers/assertio= ns). Because of how the protocol works, the client software now has a better= opportunity to present information to the AS, either directly in the reques= t or by introducing the AS to another software component during the =E2=80=9C= interaction=E2=80=9D phase. So, what if we think of the AS primarily as a =E2= =80=9Ctoken issuer=E2=80=9D? 

    For example, if t= he client can present a verifiable credential (VC) that represents the end u= ser, the AS can validate that VC and make an access token on behalf of that u= ser, without having the user log in or interact with the AS at all. This VC c= an contain whatever access rights the token needs to represent, and the AS c= an translate that into an artifact that the downstream RS=E2=80=99s can inte= rpret, without having to see the original VC or the user at all. The AS is s= till HTTP based, but all the essential security and rights elements are prov= ided by the wallet. In this way, we can expand on the privacy-preserving asp= ects of OAuth and bridge the worlds of SSI and web APIs without violating th= e basic nature of either.

    Coming from the OAuth wor= ld, it feels weird to issue tokens like this, but there=E2=80=99s precedent f= or this kind of thing. Today, a there are a number of service-based OAuth AS= 's that are told what claims need to get put into the access token by some t= rusted component. All of this happens outside the OAuth protocol. In GNAP, I= think it makes sense to account for this kind of thing in how we define the= protocol. That isn=E2=80=99t to say all of these pieces need to be defined i= n the core, but the base protocol ought to be able to handle being extended i= n this direction as needed.

    I=E2=80=99m really inte= rested to hear other people=E2=80=99s thoughts on how this could come togeth= er.

     =E2=80=94 Justin
    --
    = TXAuth mailing list
    TXAu= th@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    = https://www.i= etf.org/mailman/listinfo/txauth

    This communication, including any attac=
hments, is confidential. If you are not the intended recipient, you should n=
ot read it - please contact me immediately, destroy it, and do not copy or u=
se any part of this communication or disclose anything about it. Thank you. P=
lease note that this communication does not designate an information system f=
or the purposes of the Electronic Transactions Act 2002.

    --
    TXAuth mailing list
    TXAuth@ietf.org
    = https://www.i= etf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.or= g
    https://www.google.com/url?q=3Dhttps://www.ietf.org/mailma= n/listinfo/txauth&source=3Dgmail-imap&ust=3D1614379828000000&usg= =3DAOvVaw3avsUGQ48fo1OUQV0vyyKd
    = --Apple-Mail-F5F304CA-3796-4F63-AC42-B349AF5A5E08-- --Apple-Mail-3624BD70-AD67-41BF-AB0D-E19D0F3F7BB5 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBPgw ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wxggOpMIIDpQIBATCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgM B0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5w LkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjIxMDkzNDE2WjAvBgkqhkiG9w0BCQQxIgQg Rrwx1oU6uAiQX8AaDa0jMN78XMWTyExDFHACLYs1NNYwgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQELBQAEggEAG1cUD33/4ZeWe7KN/fNVLHhLTtcIxBLUgt0T648M5flPwIO6vFUb 5vDoJNILcngP3prSzQov/UsWoYBy0fhE6PosgVJZKU0TDTbDCJB/acSSAP+yO+pjgl3qzTPK0qKZ cth6YI1+9s+63CoqhNe1NqooQy1g2xJhtaCAN/NCkZIKBe5Bsp7UkukHRvW7p2NPNrQzUjrEVD53 8MAkEaRYks/BmZ8Mj0PZAMZIxByUojy0eymJrgwHkXPAuTNaAh5UJ0eVoHNty0aOMspXoBqGe8ZW CLqdwk45Ib0qaemiY+6aSUBr1GQjVHt4afLH41+Od1HtnPZezQY65expRmC3TAAAAAAAAA== --Apple-Mail-3624BD70-AD67-41BF-AB0D-E19D0F3F7BB5-- From nobody Sun Feb 21 06:41:03 2021 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 754493A0A38 for ; Sun, 21 Feb 2021 06:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 UU-siQIqxWqy for ; Sun, 21 Feb 2021 06:40:53 -0800 (PST) Received: from mail-ua1-f42.google.com (mail-ua1-f42.google.com [209.85.222.42]) (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 58BEE3A0A06 for ; Sun, 21 Feb 2021 06:40:53 -0800 (PST) Received: by mail-ua1-f42.google.com with SMTP id c22so3360563uap.10 for ; Sun, 21 Feb 2021 06:40:53 -0800 (PST) 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=BYkgztxW323Tlk6arICr/43j9ePwrEYedgHZirJOyaA=; b=MrO/v2GKvKZyj3vsEPxPmze5EyHEbF7ZntNRAlFWyzpcjMhTkYE9gsB3BhkBjB4n8C bMBigeq9I1MQAPNnslXOfHfDcPeXdMG4SyzeXoWGuIDJ54z/k9J4cQprun75u17kEwx/ btQl6jxGNY9iZlbkCAFJWk7xbRRqQrkx5o33VfhQhPuTodskg5iADDze3OvA+8YCj99+ vT5v5/Y9t1GqBoFWbyAcMyCmcO4WmqU/Y+4DuxI5/3z7n7urXXMEj4rRbOuA4lzrvy5O bQRyEZsQGmL+OO5VpB+lYcFZodPvofutioKvQ2ST/PW0RSvvwGdiE+cRHXAto2+VSjDH h7fg== X-Gm-Message-State: AOAM5338LZXAWwKzKEJ3rMdGGahcjZBrGIC2wyHHMfdftgL6/Cckf3qr qJitgQKMbFv2dlHRproyF/dIcOyfJkpZ9Q6sJ6Q= X-Google-Smtp-Source: ABdhPJxAXif96LOOpB+0TJdKVRde8EHYZNKj78ewxONlp0deoludEd6UfdLzvZKHHZ4xWTEEkf9ZgN36faCcdzW5e+w= X-Received: by 2002:a9f:3fcf:: with SMTP id m15mr604376uaj.39.1613918451934; Sun, 21 Feb 2021 06:40:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Gropper Date: Sun, 21 Feb 2021 09:40:39 -0500 Message-ID: To: Torsten Lodderstedt Cc: Justin Richer , Fabien Imbault , txauth gnap , Tobias Looker Content-Type: multipart/alternative; boundary="0000000000000627ff05bbd9ac9d" Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2021 14:40:59 -0000 --0000000000000627ff05bbd9ac9d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Torsten, Thank you for raising all of these excellent points. I hope we can all answer them and maybe even add a section to the wiki. I'll start... You're right that OAuth deployments almost exclusively put the AS and RS in the same domain. If OAuth were adequate to today's needs we probably would not be here doing GNAP. Since OAuth, we have increasing privacy concerns and security disasters. GDPR, for example, separates the role of a data controller from a data processor and treats them as separate legal entities. To oversimplify GDPR, the data processor is spared privacy responsibility and cost. You are also right to mention open banking as a use-case. Open banking has not adopted UMA 2.0 (on which I have worked for almost a decade) which is based on OAuth. PSD2 and similar regulations do not tie the AS and RS to the same security domain but they presume a narrow federation of licensed (and regulated) ASs as payment processors for subjects to choose among. This centralization to regulated fiduciaries is a privacy trade-off that makes sense in banking. The fiduciary can be bonded so they can refund the money to the subject in case of a security breach. This privacy-security tradeoff does not make sense in healthcare and other domains where the consequences of a breach are not easily reversed. This thread is about aligning GNAP and SSI. SSI does not abide centralization, censorship, or surveillance. If GNAP makes any assumptions that result in either a tight coupling between AS and RS (surveillance) or even a federated fiduciary (centralization) we will lose out on the benefits of progress in digital identity that is now driving a lot of public-sector initiatives and starting to bleed over into private sector practices. Zero Trust Architecture is an example and OAuth is not well suited for ZTA. As you said, "technically, the respective AS and RSs set up a trust relationship and agreed on ways to share authorization and user data in order [to] enable secure API access." This is where GNAP operates and we need to avoid _any_ restrictions on either the AS or the RS being self-sovereign. Examples of a self-sovereign RS could be a personal data store or an encrypted data vault like the ones we work on in W3C/DIF. Any AS can be self-sovereign if the subject controls all of the policies and these policies are not shared, in the same way a private key is never not shared. Continuing your quote: > I read your ideas regarding self-sovereign ASs with great interest and go= t > some observations/questions: > - A personal AS could certainly control access to a person=E2=80=98s reso= urces. I > assume the person=E2=80=98s RSs would only accept access tokens signed by= the RO. > Am I right? > Yes, and. There is debate in various SSI WGs whether a RS such as an Encrypted Data Vault should respond to capabilities or tokens. Either way, the RO is in control of the signature but a personal AS is a delegate of the RO (either directly or via a mobile user agent). With capabilities such as ZCAP-LD or biscuits, the token signature allows for filtered delegation. - Do you envision this AS to be able to control access to any kind of RS? > How is the AS supposed to know what authorization data this RS needs in > order to perform access control decisions? What data will be exchanged? > Yes. The whole point, as far as I'm concerned, is to design human centered standards. This is how W3C and IETF are different. Other SDOs tend to be operated for institutional benefit. A person-centered AS must work across institutional domains. This, as you point out, brings up the problem of scope. Ontologies and data models are, justifiably, domain-specific. I, for example, work around the HL7 data model standards and APIs like FHIR that are controlled by healthcare business interests. It's unreasonable to expect a general solution to the data model problem, although folks of the Linked Data persuasion might disagree. Every RS gets to decide what data models and ontologies it supports. These decisions are public and sometimes standardized for the benefit of the clients. A person's AS must read and maybe understand the RS data model in order to issue tokens just like the client needs to do in order to make a request to the AS. In our HIE of One Trustee project, we allow the self-sovereign subject to inherit AS policies from self-sovereign communities they choose and then modify the policies if they want. In this way, communities compete for members on the basis of policy bundles the same way churches compete for congregants. - How would this person delegate access to her resources to someone else? > There are two "persons" to consider. The RO delegates to an RQ. But the RQ, in real life, is part of a team and often delegates to associates. With or without capabilities, GNAP needs to deal with this reality that RO and RQ user agents may be different from the client that actually presents a token to the RS. Some of this difference between user agents and clients we may be able to keep out of band. - Are you aware of deployments implementing this philosophy? > Other than our HIE of One demonstration project in healthcare, no. We started HIE of One before SSI in order to drive the transition from UMA to UMA 2.0 and inform various healthcare regulatory priorities. We then jumped on SSI immediately and added it to the UMA 2 AS we call Trustee. Now we are trying to align SSI and GNAP in order to enable human-centered protocols and zero-trust architecture. > - What are the implications in terms of user experience? Right now, the human-centered user experience assumes a secure element and web browser as user agents on a mobile device. Neither of these is readily accessible as a server nor are they designed to accept code plug-ins that represent the policies of an AS. One major exception is people adding advertising and surveillance blockers like EFF Privacy Badger to their browser. The user experience implications of having SSI data model standards and GNAP protocol standards is that today's password managers (I have 250 RS relationships in mine) will evolve to also control an AS agent. Just like I might register a W3C DID with an RS instead of an email address, my policy manager might display to me the token policies that will be applied by my AS to the personal data I can control at that RS. In some cases, my AS will allow me to modify those policies just like the obnoxious cookie policy settings do today. The BIG difference with GNAP is that I choose my AS separately from the RS so the dark patterns associated with today's cookie policies experience are no longer possible. GNAP means the RS exposes an API rather than a UI. I've gone on far too long to address the issue of the AS as an identity provider. It's fair to think of it that way. As it turns out, in the SSI Secure Data Storage WG, we are debating the difference between an Encrypted Data Vault and an Identity Hub. As far as I'm concerned, the Identity Hub is mostly a GNAP AS. Join us on Thursdays at 4 PM ET https://lists.identity.foundation/g/sds-wg/wiki/Home Adrian On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt wrote: > > > Am 19.02.2021 um 23:50 schrieb Adrian Gropper : > > =EF=BB=BF > I agree with the first two of Justin's responses but not the last one. > > It's confusing to think that there are more RS than AS. > > > the OAuth deployments I=E2=80=98m aware of typically have much more RSs t= han ASs. > Why? Because AS and a set of RSs belong to the same security domain (e.g.= a > certain business) and it=E2=80=99s the AS=E2=80=99s responsibility to ens= ure secure and > convenient access to the APIs provided by this RSs. For example: there is= a > AS controlling access to a cloud, streaming, and messaging services of th= e > same business. In case of open banking, the bank=E2=80=98s AS is (on beha= lf of the > user) authorizing access to APIs for account information as well as payme= nt > initiation and potentially other services. > > Technically, the respective AS and RSs set up a trust relationship and > agreed on ways to share authorization and user data in order enable secur= e > API access. > > I read your ideas regarding self-sovereign ASs with great interest and go= t > some observations/questions: > - A personal AS could certainly control access to a person=E2=80=98s reso= urces. I > assume the person=E2=80=98s RSs would only accept access tokens signed by= the RO. > Am I right? > - Do you envision this AS to be able to control access to any kind of RS? > How is the AS supposed to know what authorization data this RS needs in > order to perform access control decisions? What data will be exchanged? > - How would this person delegate access to her resources to someone else? > - Are you aware of deployments implementing this philosophy? > - What are the implications in terms of user experience? > > In my experience coupling between AS and RS is very tight. I have a hard > time to see how self-sovereign ASs would work. It feels like such an AS i= n > the end is an identity provider of some sort, which brings me to what > Justin proposed. I would assume using SSI credentials to authenticate > towards ASs is feasible and might have value but I=E2=80=98m skeptical ab= out the AS > part. > > best regards, > Torsten. > > From a human-centered (and hopefully IETF) perspective, each person might > control or specify a different AS for each of their personas or for each > child or incompetent delegate of them as guardian. We're familiar with > separate gmail addresses for each persona. > > ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial > bitcoin wallet), or brokers (as in data brokers and surveillance > capitalism). Any RS that is willing to have a recurring relationship with= a > persona could accept a GNAP AS endpoint instead of an email address. This > is easiest using HTTP, but GNAP need not exclude other RS / AS APIs and > transports. Designing around the uncensored specification of one's AS as = a > human right would greatly simplify many aspects of GNAP adoption. > > That said, GNAP should not ignore the RS business or > jurisdictional reasons to limit the authority of the AS. UMA 2.0 spent > years dancing around this issue with ideas like "cascading" AS and variou= s > centralized or federated AS concepts. My conclusion is that any RS can > always do whatever it wants and there's not much the authorization protoc= ol > can help with other than specifying a notification endpoint so that an RS > can warn (and seek confirmation) or log various exceptions. This turns ou= t > to be, after a year of testimony, the regulation that applies to HIPAA RS > APIs in the US. For this reason GNAP might include a notification protoco= l > in the AS specification, or not. > > I propose that embracing a self-sovereign agent is key to harmonizing the > SSI and GNAP standards. > > Adrian > > On Fri, Feb 19, 2021 at 2:30 PM Justin Richer wrote: > >> Tobias, thanks for the great observations. Some reactions inline below. >> >> On Feb 18, 2021, at 7:59 PM, Tobias Looker >> wrote: >> >> Justin, >> >> I think this is a great and timely conversation to be having given the >> current interest around SSI and efforts like SIOP, I have been doing qui= te >> a bit of work in this space as of recent, so thought I'd add a few of th= e >> observations that I've made. >> >> In my opinion SIOP was really a bucket for solving quite a few different >> problems, not just one. In particular I think its intent was to solve 3 >> major ones: >> >> 1. Enabling portable identities >> 2. Solving the NASCAR problem >> 3. Exploring different deployment models for the provider >> >> To drill down briefly on these, note much of my terminology is OpenID >> based due to SIOPs origin >> >> *Enabling portable identities *- In general today in the case of OpenID, >> the end-users identity as understood by a relying party is scoped within >> the domain of the provider. Which means if that provider goes out of >> business or for whatever reason decides to no longer offer the same >> identity services to the End-User, their identity is essentially gone. >> Whilst there has been some interesting related work from groups like MOD= RNA >> on solutions to combat this like 'Account Porting', they often assume th= e >> old provider remains online and willing to facilitate in the account >> porting process so that the End-User can migrate to a new provider. SIOP >> actually elected to do something different here by using cryptography, >> instead of the End-User identifier being something like a GUID asserted >> within the domain of the provider, SIOP defined this instead as a public >> key fingerprint associated to a private key that's assumed to be under t= he >> control of the user. In doing so the identity itself becomes portable >> between providers by transferring the associated private key. Now this >> approach does have drawbacks and arguably encourages what many would ref= er >> to as bad cryptographic practise by not allowing any way to do key >> rotation, however the idea was there. >> >> *How GNAP can solve for this?* By having flexibility around how the >> resource owner / End-User is referred to by the Authorization server (e.= g >> allow the identifier to be something like a public key or a resolvable >> identifier to public keys such as a DID) >> >> >> I personally think that GNAP should be a flexible :carrier: of >> identifiers and other bits of identity information. This is the main rea= son >> we went with the Subject Identifiers draft from SECEVENT: it=E2=80=99s s= et up to >> talk about a variety of different kinds of identifiers, all of them >> asserted in the context of the AS. If there=E2=80=99s a definition for a= DID URL or >> a JWK in the sub_ids object structure, GNAP would be able to just use it >> directly alongside every other format. I haven=E2=80=99t seen those prop= osed yet, >> but it would be easy to do and, in my mind, would be a better solution t= han >> the portable identifiers proposal that was recently brought up in the FA= PI >> working group in OIDF. (A side note, but the main problem I have here is >> that it=E2=80=99s pasting semantics and formats onto a field where none = existed >> before, and that=E2=80=99s rife for problems. Better to have a structure= that takes >> that into account from the start, in my view.) >> >> >> *Solving the NASCAR problem *- One of those enduring problems in >> identity systems, which I think is really about the three way negotiatio= n >> going on between the RP, the End-User and the Provider. SIOP's solution >> pushed for most of the power in this decision making process to lie with >> the End-User, letting them decide who they want as their provider rather >> than RP's providing an enumeration of who they support via provider icon= s >> on their login page and End-Users having to select from those options. I= t >> accomplished this via using a custom URL scheme of `openid://` where the >> End-User would register their chosen provider as a protocol handler for = the >> `openid://` scheme. However, again as a solution it's not without it's >> challenges, notably; only a single registration at a time can be support= ed, >> the actual identity of the provider remains blind to the RP until after = the >> request is sent and it requires registration or some form of default >> handling (e.g when there is no provider registered). >> >> *How GNAP can solve for this?* I actually don't think this is core to >> GNAP, there may be some considerations around discovery that are worth >> paying attention to but not much in the core protocol design. >> >> >> SIOP doesn=E2=80=99t really solve the NASCAR issue since SIOP, by design= , becomes >> yet one more login option among many. I think GNAP can help this by >> enabling user-directed provider discovery to kick off the process, but I >> agree that the core protocol doesn=E2=80=99t really have much to say her= e, and >> shouldn=E2=80=99t. >> >> *Exploring different deployment models for the provider* - This is the >> most frequently talked about aspect of SIOP and perhaps the most >> interesting to GNAP. I like to think about the scope of this issue as >> designing to allow for either a partially or fully >> distributed/decentralized provider, rather than a centralized one (e.g a= n >> HTTP based AuthZ server). As you noted this does come with its challenge= s >> many of which are technical in nature, i.e how to appropriately address = a >> decentralized provider and what protocols are used to communicate with t= he >> provider. >> >> *How GNAP can solve for this?* I think that's what much of the >> discussion on this thread will be about and whether there is a hybrid mo= del >> where some responsibility is still centrally administered like token >> issuance, while allowing other aspects to occur in a more distributed >> manner. Ideally though I'd like to see consideration for a completely >> distributed model too. >> >> >> I agree that this seems to be the most interesting place for overlap. I >> don=E2=80=99t actually think the =E2=80=9Chybrid=E2=80=9D approach centr= alizes things. Instead, you >> can think of the RS as having an associated AS, and that AS accepting us= er >> consent and claims at runtime from a variety of sources (wallets, VCs, >> etc.). In this way, we aren=E2=80=99t talking about a single AS in the w= orld >> handling all of these requests, we=E2=80=99re talking about a distribute= d network >> of AS=E2=80=99s associated with an even more widely distributed set of R= S=E2=80=99s. SSI >> and its associated technologies would help these =E2=80=9Clocal=E2=80=9D= AS=E2=80=99s issue access >> tokens without the RO needing to have an account, or even necessarily >> directly interacting with the AS. There=E2=80=99s currently a technology= gap there, >> but my thoughts are that this is where the changes to the interaction mo= des >> section can really come to play. >> >> I think the notion of a non-HTTP AS is interesting, but I=E2=80=99m not = sure if >> that=E2=80=99s something GNAP ought to be solving for. I think that ther= e=E2=80=99s a deep >> value in building on top of HTTP for the core protocol, and not abstract= ing >> away concepts from it. Otherwise, you end up re-inventing layers, and yo= u >> get something like SOAP all over again. :) >> >> =E2=80=94 Justin >> >> >> Thanks, >> [image: Mattr website] >> >> >> *Tobias Looker* >> Mattr >> +64 (0) 27 378 0461 >> tobias.looker@mattr.global >> [image: Mattr website] >> [image: >> Mattr on LinkedIn] >> [image: >> Mattr on Twitter] >> [i= mage: >> Mattr on Github] >> >> This communication, including any attachments, is confidential. If you >> are not the intended recipient, you should not read it - please contact = me >> immediately, destroy it, and do not copy or use any part of this >> communication or disclose anything about it. Thank you. Please note that >> this communication does not designate an information system for the >> purposes of the Electronic Transactions Act 2002. >> >> >> On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault >> wrote: >> >>> Hi Justin, >>> >>> I agree that defining AS role primarily as a token issuer is a fruitful >>> idea. Solving this problem well would also respond to the challenges >>> discussed previously on the list. >>> >>> Cheers >>> Fabien >>> >>> >>> Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer a =C3=A9crit : >>> >>>> The last interim call had a lot of discussion on SSI technologies such >>>> as digital wallets, and how those fit with GNAP. I think it=E2=80=99s = worth >>>> continuing that conversation here on the list. There are a few issues = in >>>> the tracker that give some background, too: >>>> >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 >>>> >>>> >>>> There=E2=80=99s been a lot of interesting work recently in the OpenID >>>> Foundation around using the Self-issued OP (SIOP) functionality to >>>> bootstrap an SSI style login. This makes extensive use of the implicit= flow >>>> and front channel messaging, but minimization of the front channel for >>>> message passing is a key design tenet of GNAP (so much so that it=E2= =80=99s >>>> included in our charter). Instead, GNAP has been built around an idea = that >>>> everything starts the same way: with an HTTP request to the AS. >>>> >>>> The idea of an on-device AS has been brought up a lot, and we need to >>>> consider if and how we want to deal with these kinds of use cases. The= most >>>> obvious way to address these would be to do some kind of clever off-HT= TP >>>> hack like SIOP, but keep in mind that even SIOP generally starts off w= ith >>>> an HTTP-based discovery call by the RP to make things work. >>>> >>>> My personal stance is that to do this, we need to re-evaluate our >>>> assumptions about exactly what an AS does and what it needs to do thos= e >>>> things. In OAuth 2, it=E2=80=99s assumed that the AS is the device tha= t=E2=80=99s >>>> authenticating the user, collecting consent, managing the client=E2=80= =99s >>>> registration, and creating an access token based on whatever set of ri= ghts >>>> that are associated with all of those things. In UMA, this is turned a= round >>>> a bit by letting the RO present a bunch of nebulous =E2=80=9Cclaims=E2= =80=9D interactively, >>>> but still at the AS. >>>> >>>> With both of these, a key aspect remains: the AS needs to gather >>>> necessary information, and issue the access token (or >>>> identifiers/assertions). Because of how the protocol works, the client >>>> software now has a better opportunity to present information to the AS= , >>>> either directly in the request or by introducing the AS to another sof= tware >>>> component during the =E2=80=9Cinteraction=E2=80=9D phase. So, what if = we think of the AS >>>> primarily as a =E2=80=9Ctoken issuer=E2=80=9D? >>>> >>>> For example, if the client can present a verifiable credential (VC) >>>> that represents the end user, the AS can validate that VC and make an >>>> access token on behalf of that user, without having the user log in or >>>> interact with the AS at all. This VC can contain whatever access right= s the >>>> token needs to represent, and the AS can translate that into an artifa= ct >>>> that the downstream RS=E2=80=99s can interpret, without having to see = the original >>>> VC or the user at all. The AS is still HTTP based, but all the essenti= al >>>> security and rights elements are provided by the wallet. In this way, = we >>>> can expand on the privacy-preserving aspects of OAuth and bridge the w= orlds >>>> of SSI and web APIs without violating the basic nature of either. >>>> >>>> Coming from the OAuth world, it feels weird to issue tokens like this, >>>> but there=E2=80=99s precedent for this kind of thing. Today, a there a= re a number >>>> of service-based OAuth AS's that are told what claims need to get put = into >>>> the access token by some trusted component. All of this happens outsid= e the >>>> OAuth protocol. In GNAP, I think it makes sense to account for this ki= nd of >>>> thing in how we define the protocol. That isn=E2=80=99t to say all of = these pieces >>>> need to be defined in the core, but the base protocol ought to be able= to >>>> handle being extended in this direction as needed. >>>> >>>> I=E2=80=99m really interested to hear other people=E2=80=99s thoughts = on how this could >>>> come together. >>>> >>>> =E2=80=94 Justin >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >> >> This communication, including any attachments, is confidential. If you a= re not the intended recipient, you should not read it - please contact me i= mmediately, destroy it, and do not copy or use any part of this communicati= on or disclose anything about it. Thank you. Please note that this communic= ation does not designate an information system for the purposes of the Elec= tronic Transactions Act 2002. >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> > -- > TXAuth mailing list > TXAuth@ietf.org > > https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txau= th&source=3Dgmail-imap&ust=3D1614379828000000&usg=3DAOvVaw3avsUGQ48fo1OUQV0= vyyKd > > --0000000000000627ff05bbd9ac9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Tors= ten,

    Thank you for raising all of these excellent points= . I hope we can all answer them and maybe even add a section to the wiki. I= 'll start...

    You're right that OAuth deplo= yments almost exclusively put the AS and RS in the same domain. If OAuth we= re adequate to today's needs we probably would not be here doing GNAP. = Since OAuth, we have increasing privacy concerns and security disasters. GD= PR, for example, separates the role of a data controller from a data proces= sor and treats them as separate legal entities. To oversimplify GDPR, the d= ata processor is spared privacy responsibility and cost.

    You are also right to mention open banking as a use-case. Open banki= ng has not adopted UMA 2.0 (on which I have worked for almost a decade) whi= ch is based on OAuth. PSD2 and similar regulations do not tie the AS and RS= to the same security domain but they presume a narrow federation of licens= ed (and regulated) ASs as payment processors for subjects to choose among. = This centralization to regulated fiduciaries is a privacy trade-off that ma= kes sense in banking. The fiduciary can be bonded so they can refund the mo= ney to the subject in case of a security breach. This privacy-security trad= eoff does not make sense in healthcare and other domains where the conseque= nces of a breach are not easily reversed.

    This thr= ead is about aligning GNAP and SSI. SSI does not abide centralization, cens= orship, or surveillance. If GNAP makes any assumptions that result in eithe= r a tight coupling between AS and RS (surveillance) or even a federated fid= uciary (centralization) we will lose out on the benefits of progress in dig= ital identity that is now driving a lot of public-sector initiatives and st= arting to bleed over into private sector practices. Zero Trust Architecture= is an example and OAuth is not well suited for ZTA.

    As you said, "technically, the respective AS and RSs set up a trust= relationship and agreed on ways to share authorization and user data in or= der [to] enable secure API access." This is where GNAP operates and we= need to avoid _any_ restrictions on either the AS or the RS being self-sov= ereign. Examples of a self-sovereign RS could be a personal data store or a= n encrypted data vault like the ones we work on in W3C/DIF. Any AS can be s= elf-sovereign if the subject controls all of the policies and these policie= s are not shared, in the same way a private key is never not shared.=C2=A0<= /div>

    Continuing your quote:
    = I read your ideas regarding self-sovereign ASs with great interest and got = some observations/questions:
    - A personal AS could certainly control acc= ess to a person=E2=80=98s resources. I assume the person=E2=80=98s RSs woul= d only accept access tokens signed by the RO. Am I right?
    <= div>Yes, and. There is debate in various SSI WGs whether a RS such as an En= crypted Data Vault should respond to capabilities or tokens. Either way, th= e RO is in control of the signature but a personal AS is a delegate of the = RO (either directly or via a mobile user agent). With capabilities=C2=A0suc= h as ZCAP-LD or biscuits, the token signature=C2=A0allows for filtered dele= gation.

    - Do you envision this AS to b= e able to control access to any kind of RS? How is the AS supposed to know = what authorization data this RS needs in order to perform access control de= cisions? What data will be exchanged?
    Yes. The whole p= oint, as far as I'm concerned, is to design human centered standards. T= his is how W3C and IETF are different. Other SDOs tend to be operated for i= nstitutional benefit. A person-centered AS must work across institutional d= omains.=C2=A0

    This, as you point out, brings up th= e problem of scope. Ontologies and data models are, justifiably, domain-spe= cific. I, for example, work around the HL7 data model standards and APIs li= ke FHIR that are controlled by healthcare business interests. It's unre= asonable to expect a general solution to the data model problem, although f= olks of the Linked Data persuasion might disagree.

    Every RS gets to decide what data models and ontologies it supports. These= decisions are public and sometimes standardized for the benefit of the cli= ents. A person's AS must read and maybe understand the RS data model in= order to issue tokens just like the client needs to do in order to make a = request to the AS. In our HIE of One Trustee project, we allow the self-sov= ereign subject to inherit AS policies from self-sovereign communities they = choose and then modify the policies if they want. In this way, communities = compete for members on the basis of policy bundles the same way churches co= mpete for congregants.

    - How would thi= s person delegate access to her resources to someone else?
    =
    There are two "persons" to consider. The RO delegates to an = RQ. But the RQ, in real life, is part of a team and often delegates to asso= ciates. With or without capabilities, GNAP needs to deal with this reality = that RO and RQ user agents may be different from the client that actually p= resents a token to the=C2=A0RS. Some of this difference between user agents= and clients we may be able to keep out of band.

    - Are you aware of deployments implementing this philosophy?
    =
    Other than our HIE of One demonstration project in health= care, no. We started HIE of One before SSI in order to drive the transition= from UMA to UMA 2.0 and inform various healthcare regulatory=C2=A0prioriti= es. We then jumped on SSI immediately and added it to the UMA 2 AS we call = Trustee. Now we are trying to align SSI and GNAP in order to enable human-c= entered protocols and zero-trust architecture.=C2=A0
    =C2=A0
    =
    - What are the implications in terms of user experience?
    Right now, the human-centered user experience assumes a sec= ure element and web browser as user agents on a mobile device. Neither of t= hese is readily accessible=C2=A0as a server nor are they designed to accept= code plug-ins that represent the policies of an AS. One major exception is= people adding advertising and surveillance blockers like EFF Privacy Badge= r to their browser.=C2=A0

    The user experienc= e implications of having SSI data model standards and GNAP protocol standar= ds is that today's password managers (I have 250 RS relationships in mi= ne) will evolve to also control an AS agent. Just like I might register a W= 3C DID with an RS instead of an email address, my policy manager might disp= lay to me the token policies that will be applied by my AS to the personal = data I can control at that RS.=C2=A0

    In some cases= , my AS will allow me to modify those policies just like the obnoxious cook= ie policy settings do today. The BIG difference with GNAP is that I choose = my AS separately from the RS so the dark patterns associated with today'= ;s cookie policies experience are no longer possible. GNAP means the RS exp= oses an API rather than a UI.

    I've gone on far= too long to address the issue of the AS as an identity provider. It's = fair to think of it that way. As it turns out, in the SSI Secure Data Stora= ge WG, we are debating the difference between an Encrypted Data Vault and a= n Identity Hub. As far as I'm concerned, the Identity Hub is mostly a G= NAP AS. Join us on Thursdays at 4 PM ET=C2=A0https://lists.identity.foundation/g/sds-= wg/wiki/Home=C2=A0

    Adrian

    =


    On Sun, Feb 21, 2021 at 4:34 AM Torsten Lo= dderstedt <= torsten@lodderstedt.net> wrote:


    Am 19.02.2021 um 23:50 schrieb Adrian Gropper <agropper@healthurl.com>= :

    =EF= =BB=BF
    I agree with the=C2=A0first=C2=A0two of Justin's= responses but not the last one.

    It's confusing to t= hink that there are more RS than AS.
    the OAuth deployments I=E2=80=98m aware of typically have much = more RSs than ASs. Why? Because AS and a set of RSs belong to the same secu= rity domain (e.g. a certain business) and it=E2=80=99s the AS=E2=80=99s res= ponsibility to ensure secure and convenient access to the APIs provided by = this RSs. For example: there is a AS controlling access to a cloud, streami= ng, and messaging services of the same business. In case of open banking, t= he bank=E2=80=98s AS is (on behalf of the user) authorizing access to APIs = for account information as well as payment initiation and potentially other= services.=C2=A0

    Technically, the respective AS an= d RSs set up a trust relationship and agreed on ways to share authorization= and user data in order enable secure API access.

    = I read your ideas regarding self-sovereign ASs with great interest and got = some observations/questions:
    - A personal AS could certainly cont= rol access to a person=E2=80=98s resources. I assume the person=E2=80=98s R= Ss would only accept access tokens signed by the RO. Am I right?
    = - Do you envision this AS to be able to control access to any kind of RS? H= ow is the AS supposed to know what authorization data this RS needs in orde= r to perform access control decisions? What data will be exchanged?
    - How would this person delegate access to her resources to someone else= ?
    - Are you aware of deployments implementing this philosophy?
    - What are the implications in terms of user experience?
    =
    In my experience coupling between AS and RS is very tight. I= have a hard time to see how self-sovereign ASs would work. It feels like s= uch an AS in the end is an identity provider of some sort, which brings me = to what Justin proposed. I would assume using SSI credentials to authentica= te towards ASs is feasible and might have value but I=E2=80=98m skeptical a= bout the AS part.

    best regards,
    Torsten.=

    = From a human-centered (and hopefully IETF) perspective, each person might = control or specify a different AS for each of their personas or for each ch= ild or incompetent delegate of them as guardian. We're familiar with se= parate gmail addresses for each persona.

    ASs will = be self-sovereign (as in SSI), fiduciary (as in a custodial bitcoin wallet)= , or brokers (as in data brokers and surveillance capitalism). Any RS that = is willing to have a recurring relationship with a persona could accept a G= NAP AS endpoint instead of an email address. This is easiest using HTTP, bu= t GNAP need not exclude other RS / AS APIs and transports. Designing around= the uncensored specification=C2=A0of one's AS as a human right would g= reatly simplify many aspects of GNAP adoption.

    Tha= t said, GNAP should not ignore the RS business or jurisdictional=C2=A0reaso= ns to limit the authority of the AS. UMA 2.0 spent years dancing around thi= s issue with ideas like "cascading" AS and various centralized or= federated AS concepts. My conclusion is that any RS can always do whatever= it wants and there's not much the authorization protocol can help with= other than specifying a notification endpoint so that an RS can warn (and = seek confirmation) or log various exceptions. This turns out to be, after a= year of testimony, the regulation that applies to HIPAA RS APIs in the US.= For this reason GNAP might include a notification protocol in the AS speci= fication, or not.

    I propose that embracing a self-= sovereign agent is key to harmonizing the SSI and GNAP standards.

    Adrian

    On Fri, Feb 19, 2021 at 2:30 PM Justin Richer= <jricher@mit.edu> wrote:
    Tobias, thanks for the great observations. So= me reactions inline below.

    On Fe= b 18, 2021, at 7:59 PM, Tobias Looker <tobias.looker@mattr.global> wrote:
    Justin,

    I think this is a great and tim= ely conversation to be having given the current interest around SSI and eff= orts like SIOP, I have been doing quite a bit of work in this space as of r= ecent, so thought I'd add a few of the observations that I've made.=

    In my opinion SIOP was really a bucket for solving quite a few diff= erent problems, not just one. In particular I think its intent was to solve= 3 major ones:

    1. Enabling portable identities
    2. Solving the NAS= CAR problem
    3. Exploring different deployment models for the provider
    To drill down briefly on these, note much of my terminology is OpenID = based due to SIOPs origin=C2=A0

    Enabling portable identities = - In general today in the case of OpenID, the end-users identity as underst= ood by a relying party is scoped within the domain of the provider. Which m= eans if that provider goes out of business or for whatever reason decides t= o no longer offer the same identity services to the End-User, their identit= y is essentially gone. Whilst there has been some interesting related work = from groups like MODRNA on solutions to combat this like 'Account Porti= ng', they often assume the old provider remains online and willing to f= acilitate in the account porting process so that the End-User can migrate t= o a new provider. SIOP actually elected to do something different here by u= sing cryptography, instead of the End-User identifier being something like = a GUID asserted within the domain of the provider, SIOP defined this instea= d as a public key fingerprint associated to a private key that's assume= d to be under the control of the user. In doing so the identity itself beco= mes portable between providers by transferring the associated private key. = Now this approach does have drawbacks and arguably encourages what many wou= ld refer to as bad cryptographic practise by not allowing any way to do key= rotation, however the idea was there.=C2=A0

    How GNAP= can solve for this? By having flexibility around how the resource owne= r / End-User is referred to by the Authorization server (e.g allow the iden= tifier to be something like a public key or a resolvable identifier to publ= ic keys such as a DID)

    I personally think that GNAP should be a flexible :carrier: of identifier= s and other bits of identity information. This is the main reason we went w= ith the Subject Identifiers draft from SECEVENT: it=E2=80=99s set up to tal= k about a variety of different kinds of identifiers, all of them asserted i= n the context of the AS. If there=E2=80=99s a definition for a DID URL or a= JWK in the sub_ids object structure, GNAP would be able to just use it dir= ectly alongside every other format. I haven=E2=80=99t seen those proposed y= et, but it would be easy to do and, in my mind, would be a better solution = than the portable identifiers proposal that was recently brought up in the = FAPI working group in OIDF. (A side note, but the main problem I have here = is that it=E2=80=99s pasting semantics and formats onto a field where none = existed before, and that=E2=80=99s rife for problems. Better to have a stru= cture that takes that into account from the start, in my view.)


    Solving the NASCA= R problem - One of those enduring problems in identity systems, which I= think is really about the three way negotiation going on between the RP, t= he End-User and the Provider. SIOP's solution pushed for most of the po= wer in this decision making process to lie with the End-User, letting them = decide who they want as their provider rather than RP's providing an en= umeration of who they support via provider icons on their login page and En= d-Users having to select from those options. It accomplished this via using= a custom URL scheme of `openid://` where the End-User would registe= r their chosen provider as a protocol handler for the `openid://` sc= heme. However, again as a solution it's not without it's challenges= , notably; only a single registration at a time can be supported, the actua= l identity of the provider remains blind to the RP until after the request = is sent and it requires registration or some form of default handling (e.g = when there is no provider registered).

    How GNAP can solve for thi= s? I actually don't think this is core to GNAP, there may be some c= onsiderations around discovery that are worth paying attention to but not m= uch in the core protocol design.


    SIOP doesn=E2=80=99t really solve the NASCAR issue since SI= OP, by design, becomes yet one more login option among many. I think GNAP c= an help this by enabling user-directed provider discovery to kick off the p= rocess, but I agree that the core protocol doesn=E2=80=99t really have much= to say here, and shouldn=E2=80=99t.

    Exploring different deployment models for the pr= ovider - This is the most frequently talked about aspect of SIOP and pe= rhaps the most interesting to GNAP. I like to think about the scope of this= issue as designing to allow for either a partially or fully distributed/de= centralized provider, rather than a centralized one (e.g an HTTP=C2=A0based= AuthZ server). As you noted this does come with its challenges many of whi= ch are technical in nature, i.e how to appropriately address a decentralize= d provider and what protocols are used to communicate with the provider.
    How GNAP can solve for this? I think that's=C2=A0what much= of the discussion on this thread will be about and whether there is a hybr= id model where some responsibility is still centrally administered like tok= en issuance, while allowing other aspects to occur in a more distributed ma= nner. Ideally though I'd like to see consideration for a completely dis= tributed model too.

    I agr= ee that this seems to be the most interesting place for overlap. I don=E2= =80=99t actually think the =E2=80=9Chybrid=E2=80=9D approach centralizes th= ings. Instead, you can think of the RS as having an associated AS, and that= AS accepting user consent and claims at runtime from a variety of sources = (wallets, VCs, etc.). In this way, we aren=E2=80=99t talking about a single= AS in the world handling all of these requests, we=E2=80=99re talking abou= t a distributed network of AS=E2=80=99s associated with an even more widely= distributed set of RS=E2=80=99s. SSI and its associated technologies would= help these =E2=80=9Clocal=E2=80=9D AS=E2=80=99s issue access tokens withou= t the RO needing to have an account, or even necessarily directly interacti= ng with the AS. There=E2=80=99s currently a technology gap there, but my th= oughts are that this is where the changes to the interaction modes section = can really come to play.=C2=A0

    I think the notion = of a non-HTTP AS is interesting, but I=E2=80=99m not sure if that=E2=80=99s= something GNAP ought to be solving for. I think that there=E2=80=99s a dee= p value in building on top of HTTP for the core protocol, and not abstracti= ng away concepts from it. Otherwise, you end up re-inventing layers, and yo= u get something like SOAP all over again. :)

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


    Th= anks,
    =
    3D"Mattr= =C2=A0
    Tobias Looker
    Mattr
    +64 (0) 27 378 0461
    tobias.looker@mattr.= global
    <= td width=3D"40">3D"Mattr
    3D"Mattr3D"Mattr=3D"Mattr

    This communication, in= cluding any attachments, is confidential. If you are not the intended recip= ient, you should not read it - please contact me immediately, destroy it, a= nd do not copy or use any part of this communication or disclose anything a= bout it. Thank you. Please note that this communication does not designate = an information system for the purposes of the Electronic Transactions Act 2= 002.


    On Thu, Feb 18, 2021 at 9:19 PM= Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi Justin,

    I= agree that defining AS role primarily as a token issuer is a fruitful idea= . Solving this problem well would also respond to the challenges discussed = previously on the list.=C2=A0

    Cheers
    Fabien=C2=A0


    Le mer. 17= f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:
    <= /div>
    The last interim call had a lot of discussion on= SSI technologies such as digital wallets, and how those fit with GNAP. I t= hink it=E2=80=99s worth continuing that conversation here on the list. Ther= e are a few issues in the tracker that give some background, too:

    <= /div>

    There=E2=80=99s been a lot of interes= ting work recently in the OpenID Foundation around using the Self-issued OP= (SIOP) functionality to bootstrap an SSI style login. This makes extensive= use of the implicit flow and front channel messaging, but minimization of = the front channel for message passing is a key design tenet of GNAP (so muc= h so that it=E2=80=99s included in our charter). Instead, GNAP has been bui= lt around an idea that everything starts the same way: with an HTTP request= to the AS.=C2=A0

    The idea of an on-device AS has = been brought up a lot, and we need to consider if and how we want to deal w= ith these kinds of use cases. The most obvious way to address these would b= e to do some kind of clever off-HTTP hack like SIOP, but keep in mind that = even SIOP generally starts off with an HTTP-based discovery call by the RP = to make things work.

    My personal stance is that to= do this, we need to re-evaluate our assumptions about exactly what an AS d= oes and what it needs to do those things. In OAuth 2, it=E2=80=99s assumed = that the AS is the device that=E2=80=99s authenticating the user, collectin= g consent, managing the client=E2=80=99s registration, and creating an acce= ss token based on whatever set of rights that are associated with all of th= ose things. In UMA, this is turned around a bit by letting the RO present a= bunch of nebulous =E2=80=9Cclaims=E2=80=9D interactively, but still at the= AS.=C2=A0

    With both of these, a key aspect remain= s: the AS needs to gather necessary information, and issue the access token= (or identifiers/assertions). Because of how the protocol works, the client= software now has a better opportunity to present information to the AS, ei= ther directly in the request or by introducing the AS to another software c= omponent during the =E2=80=9Cinteraction=E2=80=9D phase. So, what if we thi= nk of the AS primarily as a =E2=80=9Ctoken issuer=E2=80=9D?=C2=A0

    For example, if the client can present a verifiable credent= ial (VC) that represents the end user, the AS can validate that VC and make= an access token on behalf of that user, without having the user log in or = interact with the AS at all. This VC can contain whatever access rights the= token needs to represent, and the AS can translate that into an artifact t= hat the downstream RS=E2=80=99s can interpret, without having to see the or= iginal VC or the user at all. The AS is still HTTP based, but all the essen= tial security and rights elements are provided by the wallet. In this way, = we can expand on the privacy-preserving aspects of OAuth and bridge the wor= lds of SSI and web APIs without violating the basic nature of either.
    =

    Coming from the OAuth world, it feels weird to issue to= kens like this, but there=E2=80=99s precedent for this kind of thing. Today= , a there are a number of service-based OAuth AS's that are told what c= laims need to get put into the access token by some trusted component. All = of this happens outside the OAuth protocol. In GNAP, I think it makes sense= to account for this kind of thing in how we define the protocol. That isn= =E2=80=99t to say all of these pieces need to be defined in the core, but t= he base protocol ought to be able to handle being extended in this directio= n as needed.

    I=E2=80=99m really interested to hear= other people=E2=80=99s thoughts on how this could come together.

    =C2=A0=E2=80=94 Justin
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org https://ww= w.ietf.org/mailman/listinfo/txauth

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.

    --
    TXAuth mailing list
    TXAuth@ietf.org https://ww= w.ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.google.com/url?q= =3Dhttps://www.ietf.org/mailman/listinfo/txauth&source=3Dgmail-imap&= ;ust=3D1614379828000000&usg=3DAOvVaw3avsUGQ48fo1OUQV0vyyKd --0000000000000627ff05bbd9ac9d-- From nobody Mon Feb 22 07:47:38 2021 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B29A3A12FB; Mon, 22 Feb 2021 07:47:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: txauth@ietf.org Message-ID: <161400885600.15149.9785092293651675780@ietfa.amsl.com> Date: Mon, 22 Feb 2021 07:47:36 -0800 Archived-At: Subject: [GNAP] I-D Action: draft-ietf-gnap-core-protocol-04.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 15:47:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Grant Negotiation and Authorization Protocol WG of the IETF. Title : Grant Negotiation and Authorization Protocol Authors : Justin Richer Aaron Parecki Fabien Imbault Filename : draft-ietf-gnap-core-protocol-04.txt Pages : 117 Date : 2021-02-22 Abstract: GNAP defines a mechanism for delegating authorization to a piece of software, and conveying that delegation to the software. This delegation can include access to a set of APIs as well as information passed directly to the software. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-gnap-core-protocol-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 22 10:40:39 2021 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 8B7D03A1E99 for ; Mon, 22 Feb 2021 10:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 prPEkSQ9qAJA for ; Mon, 22 Feb 2021 10:40:32 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F043A1EE2 for ; Mon, 22 Feb 2021 10:40:32 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11MIeOvu023020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Feb 2021 13:40:26 -0500 From: Justin Richer Message-Id: <4EAA60A4-4800-400F-A70A-F7B7F1A6CB0A@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_1650D36D-995D-47ED-B120-A04DDE8DDE64" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 22 Feb 2021 13:40:23 -0500 In-Reply-To: Cc: Torsten Lodderstedt , Fabien Imbault , txauth gnap , Tobias Looker To: Adrian Gropper References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 18:40:38 -0000 --Apple-Mail=_1650D36D-995D-47ED-B120-A04DDE8DDE64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 An important aspect in the discussion here, that I agree with, is that = the RS needs to be able to decide which AS it talks to. But inherent in = that is that it=E2=80=99s not the user=E2=80=99s decision, or the AS=E2=80= =99s decision, it=E2=80=99s the RS=E2=80=99s decision who it will trust = to get tokens from. And no matter what our philosophy, at the end of the = day the RS will always have the choice of whether to trust an inbound = request. Which is why, to me, this really brings us to the question of what an AS = provides. The AS gives the RS a token that the RS decides to trust, and = that the RS can understand (either directly with something like JWT or = indirectly with something like introspection). But the AS also needs to = decide what to put INTO that token. As a consequence, the AS can get = that information from any number of places. The information could be = provided in a trusted way by the end user to the AS =E2=80=94 but this = does NOT necessarily mean that the AS belongs to the user or is under = their control.=20 Basically, I think we=E2=80=99re trying to hard to map the OAuth = general-concept of the RO having an account at the AS and logging in to = it before authorizing the request. I think that the call for =E2=80=9Cever= y user to have their own AS=E2=80=9D is such a huge non-starter in so = many domains that it hampers the solution space if that=E2=80=99s what = we presume. It=E2=80=99s up to the RS to decide who it trusts, not the = end user and not the RO.=20 I think we should ALLOW it, and we can be clearer in GNAP that that=E2=80=99= s one possible model, but not the only one, and not even the general = one. The AS manages all of the information and interconnections needed = to create an access token that the RS will accept, and it is in charge = of signaling to the RS what that token=E2=80=99s good for. However, if = the AS can learn through some other means that a specific identified = user has consented and provided appropriate information in a trusted = way, then THAT information can be baked into the token by the AS. =E2=80=94= importantly, in a way that the RS=E2=80=99s the AS protects can = understand.=20 This last bit is where general opacity of tokens is important here. = There=E2=80=99s a natural security boundary that arises from this model. = What I=E2=80=99m proposing here is just that we=E2=80=99re more explicit = about what can be put INTO that boundary. That=E2=80=99s where I=E2=80=99m= seeing a lot of this innovation in the SSI space fitting. You=E2=80=99re = not coming up with some universal access token that the RS will accept, = but you=E2=80=99re able to provide universal claims and artifacts that = an AS can process and translate into a token the RS will accept and do = the right thing with. =E2=80=94 Justin > On Feb 21, 2021, at 9:40 AM, Adrian Gropper = wrote: >=20 > Hi Torsten, >=20 > Thank you for raising all of these excellent points. I hope we can all = answer them and maybe even add a section to the wiki. I'll start... >=20 > You're right that OAuth deployments almost exclusively put the AS and = RS in the same domain. If OAuth were adequate to today's needs we = probably would not be here doing GNAP. Since OAuth, we have increasing = privacy concerns and security disasters. GDPR, for example, separates = the role of a data controller from a data processor and treats them as = separate legal entities. To oversimplify GDPR, the data processor is = spared privacy responsibility and cost. >=20 > You are also right to mention open banking as a use-case. Open banking = has not adopted UMA 2.0 (on which I have worked for almost a decade) = which is based on OAuth. PSD2 and similar regulations do not tie the AS = and RS to the same security domain but they presume a narrow federation = of licensed (and regulated) ASs as payment processors for subjects to = choose among. This centralization to regulated fiduciaries is a privacy = trade-off that makes sense in banking. The fiduciary can be bonded so = they can refund the money to the subject in case of a security breach. = This privacy-security tradeoff does not make sense in healthcare and = other domains where the consequences of a breach are not easily = reversed. >=20 > This thread is about aligning GNAP and SSI. SSI does not abide = centralization, censorship, or surveillance. If GNAP makes any = assumptions that result in either a tight coupling between AS and RS = (surveillance) or even a federated fiduciary (centralization) we will = lose out on the benefits of progress in digital identity that is now = driving a lot of public-sector initiatives and starting to bleed over = into private sector practices. Zero Trust Architecture is an example and = OAuth is not well suited for ZTA. >=20 > As you said, "technically, the respective AS and RSs set up a trust = relationship and agreed on ways to share authorization and user data in = order [to] enable secure API access." This is where GNAP operates and we = need to avoid _any_ restrictions on either the AS or the RS being = self-sovereign. Examples of a self-sovereign RS could be a personal data = store or an encrypted data vault like the ones we work on in W3C/DIF. = Any AS can be self-sovereign if the subject controls all of the policies = and these policies are not shared, in the same way a private key is = never not shared.=20 >=20 > Continuing your quote: > I read your ideas regarding self-sovereign ASs with great interest and = got some observations/questions: > - A personal AS could certainly control access to a person=E2=80=98s = resources. I assume the person=E2=80=98s RSs would only accept access = tokens signed by the RO. Am I right? > Yes, and. There is debate in various SSI WGs whether a RS such as an = Encrypted Data Vault should respond to capabilities or tokens. Either = way, the RO is in control of the signature but a personal AS is a = delegate of the RO (either directly or via a mobile user agent). With = capabilities such as ZCAP-LD or biscuits, the token signature allows for = filtered delegation. >=20 > - Do you envision this AS to be able to control access to any kind of = RS? How is the AS supposed to know what authorization data this RS needs = in order to perform access control decisions? What data will be = exchanged? > Yes. The whole point, as far as I'm concerned, is to design human = centered standards. This is how W3C and IETF are different. Other SDOs = tend to be operated for institutional benefit. A person-centered AS must = work across institutional domains.=20 >=20 > This, as you point out, brings up the problem of scope. Ontologies and = data models are, justifiably, domain-specific. I, for example, work = around the HL7 data model standards and APIs like FHIR that are = controlled by healthcare business interests. It's unreasonable to expect = a general solution to the data model problem, although folks of the = Linked Data persuasion might disagree. >=20 > Every RS gets to decide what data models and ontologies it supports. = These decisions are public and sometimes standardized for the benefit of = the clients. A person's AS must read and maybe understand the RS data = model in order to issue tokens just like the client needs to do in order = to make a request to the AS. In our HIE of One Trustee project, we allow = the self-sovereign subject to inherit AS policies from self-sovereign = communities they choose and then modify the policies if they want. In = this way, communities compete for members on the basis of policy bundles = the same way churches compete for congregants. >=20 > - How would this person delegate access to her resources to someone = else? > There are two "persons" to consider. The RO delegates to an RQ. But = the RQ, in real life, is part of a team and often delegates to = associates. With or without capabilities, GNAP needs to deal with this = reality that RO and RQ user agents may be different from the client that = actually presents a token to the RS. Some of this difference between = user agents and clients we may be able to keep out of band. >=20 > - Are you aware of deployments implementing this philosophy? > Other than our HIE of One demonstration project in healthcare, no. We = started HIE of One before SSI in order to drive the transition from UMA = to UMA 2.0 and inform various healthcare regulatory priorities. We then = jumped on SSI immediately and added it to the UMA 2 AS we call Trustee. = Now we are trying to align SSI and GNAP in order to enable = human-centered protocols and zero-trust architecture.=20 > =20 > - What are the implications in terms of user experience? > Right now, the human-centered user experience assumes a secure element = and web browser as user agents on a mobile device. Neither of these is = readily accessible as a server nor are they designed to accept code = plug-ins that represent the policies of an AS. One major exception is = people adding advertising and surveillance blockers like EFF Privacy = Badger to their browser.=20 >=20 > The user experience implications of having SSI data model standards = and GNAP protocol standards is that today's password managers (I have = 250 RS relationships in mine) will evolve to also control an AS agent. = Just like I might register a W3C DID with an RS instead of an email = address, my policy manager might display to me the token policies that = will be applied by my AS to the personal data I can control at that RS.=20= >=20 > In some cases, my AS will allow me to modify those policies just like = the obnoxious cookie policy settings do today. The BIG difference with = GNAP is that I choose my AS separately from the RS so the dark patterns = associated with today's cookie policies experience are no longer = possible. GNAP means the RS exposes an API rather than a UI. >=20 > I've gone on far too long to address the issue of the AS as an = identity provider. It's fair to think of it that way. As it turns out, = in the SSI Secure Data Storage WG, we are debating the difference = between an Encrypted Data Vault and an Identity Hub. As far as I'm = concerned, the Identity Hub is mostly a GNAP AS. Join us on Thursdays at = 4 PM ET https://lists.identity.foundation/g/sds-wg/wiki/Home = =20 >=20 > Adrian >=20 >=20 >=20 > On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt = > wrote: >=20 >=20 >> Am 19.02.2021 um 23:50 schrieb Adrian Gropper >: >>=20 >> =EF=BB=BF >> I agree with the first two of Justin's responses but not the last = one. >>=20 >> It's confusing to think that there are more RS than AS. >=20 > the OAuth deployments I=E2=80=98m aware of typically have much more = RSs than ASs. Why? Because AS and a set of RSs belong to the same = security domain (e.g. a certain business) and it=E2=80=99s the AS=E2=80=99= s responsibility to ensure secure and convenient access to the APIs = provided by this RSs. For example: there is a AS controlling access to a = cloud, streaming, and messaging services of the same business. In case = of open banking, the bank=E2=80=98s AS is (on behalf of the user) = authorizing access to APIs for account information as well as payment = initiation and potentially other services.=20 >=20 > Technically, the respective AS and RSs set up a trust relationship and = agreed on ways to share authorization and user data in order enable = secure API access. >=20 > I read your ideas regarding self-sovereign ASs with great interest and = got some observations/questions: > - A personal AS could certainly control access to a person=E2=80=98s = resources. I assume the person=E2=80=98s RSs would only accept access = tokens signed by the RO. Am I right? > - Do you envision this AS to be able to control access to any kind of = RS? How is the AS supposed to know what authorization data this RS needs = in order to perform access control decisions? What data will be = exchanged? > - How would this person delegate access to her resources to someone = else? > - Are you aware of deployments implementing this philosophy? > - What are the implications in terms of user experience? >=20 > In my experience coupling between AS and RS is very tight. I have a = hard time to see how self-sovereign ASs would work. It feels like such = an AS in the end is an identity provider of some sort, which brings me = to what Justin proposed. I would assume using SSI credentials to = authenticate towards ASs is feasible and might have value but I=E2=80=98m = skeptical about the AS part. >=20 > best regards, > Torsten. >=20 >> =46rom a human-centered (and hopefully IETF) perspective, each person = might control or specify a different AS for each of their personas or = for each child or incompetent delegate of them as guardian. We're = familiar with separate gmail addresses for each persona. >>=20 >> ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial = bitcoin wallet), or brokers (as in data brokers and surveillance = capitalism). Any RS that is willing to have a recurring relationship = with a persona could accept a GNAP AS endpoint instead of an email = address. This is easiest using HTTP, but GNAP need not exclude other RS = / AS APIs and transports. Designing around the uncensored specification = of one's AS as a human right would greatly simplify many aspects of GNAP = adoption. >>=20 >> That said, GNAP should not ignore the RS business or jurisdictional = reasons to limit the authority of the AS. UMA 2.0 spent years dancing = around this issue with ideas like "cascading" AS and various centralized = or federated AS concepts. My conclusion is that any RS can always do = whatever it wants and there's not much the authorization protocol can = help with other than specifying a notification endpoint so that an RS = can warn (and seek confirmation) or log various exceptions. This turns = out to be, after a year of testimony, the regulation that applies to = HIPAA RS APIs in the US. For this reason GNAP might include a = notification protocol in the AS specification, or not. >>=20 >> I propose that embracing a self-sovereign agent is key to harmonizing = the SSI and GNAP standards. >>=20 >> Adrian >>=20 >> On Fri, Feb 19, 2021 at 2:30 PM Justin Richer > wrote: >> Tobias, thanks for the great observations. Some reactions inline = below. >>=20 >>> On Feb 18, 2021, at 7:59 PM, Tobias Looker = > wrote: >>>=20 >>> Justin, >>>=20 >>> I think this is a great and timely conversation to be having given = the current interest around SSI and efforts like SIOP, I have been doing = quite a bit of work in this space as of recent, so thought I'd add a few = of the observations that I've made. >>>=20 >>> In my opinion SIOP was really a bucket for solving quite a few = different problems, not just one. In particular I think its intent was = to solve 3 major ones: >>>=20 >>> 1. Enabling portable identities >>> 2. Solving the NASCAR problem >>> 3. Exploring different deployment models for the provider >>>=20 >>> To drill down briefly on these, note much of my terminology is = OpenID based due to SIOPs origin=20 >>>=20 >>> Enabling portable identities - In general today in the case of = OpenID, the end-users identity as understood by a relying party is = scoped within the domain of the provider. Which means if that provider = goes out of business or for whatever reason decides to no longer offer = the same identity services to the End-User, their identity is = essentially gone. Whilst there has been some interesting related work = from groups like MODRNA on solutions to combat this like 'Account = Porting', they often assume the old provider remains online and willing = to facilitate in the account porting process so that the End-User can = migrate to a new provider. SIOP actually elected to do something = different here by using cryptography, instead of the End-User identifier = being something like a GUID asserted within the domain of the provider, = SIOP defined this instead as a public key fingerprint associated to a = private key that's assumed to be under the control of the user. In doing = so the identity itself becomes portable between providers by = transferring the associated private key. Now this approach does have = drawbacks and arguably encourages what many would refer to as bad = cryptographic practise by not allowing any way to do key rotation, = however the idea was there.=20 >>>=20 >>> How GNAP can solve for this? By having flexibility around how the = resource owner / End-User is referred to by the Authorization server = (e.g allow the identifier to be something like a public key or a = resolvable identifier to public keys such as a DID) >>=20 >> I personally think that GNAP should be a flexible :carrier: of = identifiers and other bits of identity information. This is the main = reason we went with the Subject Identifiers draft from SECEVENT: it=E2=80=99= s set up to talk about a variety of different kinds of identifiers, all = of them asserted in the context of the AS. If there=E2=80=99s a = definition for a DID URL or a JWK in the sub_ids object structure, GNAP = would be able to just use it directly alongside every other format. I = haven=E2=80=99t seen those proposed yet, but it would be easy to do and, = in my mind, would be a better solution than the portable identifiers = proposal that was recently brought up in the FAPI working group in OIDF. = (A side note, but the main problem I have here is that it=E2=80=99s = pasting semantics and formats onto a field where none existed before, = and that=E2=80=99s rife for problems. Better to have a structure that = takes that into account from the start, in my view.) >>=20 >>>=20 >>> Solving the NASCAR problem - One of those enduring problems in = identity systems, which I think is really about the three way = negotiation going on between the RP, the End-User and the Provider. = SIOP's solution pushed for most of the power in this decision making = process to lie with the End-User, letting them decide who they want as = their provider rather than RP's providing an enumeration of who they = support via provider icons on their login page and End-Users having to = select from those options. It accomplished this via using a custom URL = scheme of `openid://` <> where the End-User would register their chosen = provider as a protocol handler for the `openid://` <> scheme. However, = again as a solution it's not without it's challenges, notably; only a = single registration at a time can be supported, the actual identity of = the provider remains blind to the RP until after the request is sent and = it requires registration or some form of default handling (e.g when = there is no provider registered). >>>=20 >>> How GNAP can solve for this? I actually don't think this is core to = GNAP, there may be some considerations around discovery that are worth = paying attention to but not much in the core protocol design. >>>=20 >>=20 >> SIOP doesn=E2=80=99t really solve the NASCAR issue since SIOP, by = design, becomes yet one more login option among many. I think GNAP can = help this by enabling user-directed provider discovery to kick off the = process, but I agree that the core protocol doesn=E2=80=99t really have = much to say here, and shouldn=E2=80=99t. >>=20 >>> Exploring different deployment models for the provider - This is the = most frequently talked about aspect of SIOP and perhaps the most = interesting to GNAP. I like to think about the scope of this issue as = designing to allow for either a partially or fully = distributed/decentralized provider, rather than a centralized one (e.g = an HTTP based AuthZ server). As you noted this does come with its = challenges many of which are technical in nature, i.e how to = appropriately address a decentralized provider and what protocols are = used to communicate with the provider.=20 >>>=20 >>> How GNAP can solve for this? I think that's what much of the = discussion on this thread will be about and whether there is a hybrid = model where some responsibility is still centrally administered like = token issuance, while allowing other aspects to occur in a more = distributed manner. Ideally though I'd like to see consideration for a = completely distributed model too. >>=20 >> I agree that this seems to be the most interesting place for overlap. = I don=E2=80=99t actually think the =E2=80=9Chybrid=E2=80=9D approach = centralizes things. Instead, you can think of the RS as having an = associated AS, and that AS accepting user consent and claims at runtime = from a variety of sources (wallets, VCs, etc.). In this way, we aren=E2=80= =99t talking about a single AS in the world handling all of these = requests, we=E2=80=99re talking about a distributed network of AS=E2=80=99= s associated with an even more widely distributed set of RS=E2=80=99s. = SSI and its associated technologies would help these =E2=80=9Clocal=E2=80=9D= AS=E2=80=99s issue access tokens without the RO needing to have an = account, or even necessarily directly interacting with the AS. There=E2=80= =99s currently a technology gap there, but my thoughts are that this is = where the changes to the interaction modes section can really come to = play.=20 >>=20 >> I think the notion of a non-HTTP AS is interesting, but I=E2=80=99m = not sure if that=E2=80=99s something GNAP ought to be solving for. I = think that there=E2=80=99s a deep value in building on top of HTTP for = the core protocol, and not abstracting away concepts from it. Otherwise, = you end up re-inventing layers, and you get something like SOAP all over = again. :) >>=20 >> =E2=80=94 Justin >>=20 >>>=20 >>> Thanks, >>> = =09 >>> Tobias Looker >>> Mattr >>> +64 (0) 27 378 0461 >>> tobias.looker@mattr.global >>> = = = = >>> This communication, including any attachments, is confidential. If = you are not the intended recipient, you should not read it - please = contact me immediately, destroy it, and do not copy or use any part of = this communication or disclose anything about it. Thank you. Please note = that this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. >>>=20 >>>=20 >>> On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault = > wrote: >>> Hi Justin, >>>=20 >>> I agree that defining AS role primarily as a token issuer is a = fruitful idea. Solving this problem well would also respond to the = challenges discussed previously on the list.=20 >>>=20 >>> Cheers >>> Fabien=20 >>>=20 >>>=20 >>> Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer = > a =C3=A9crit : >>> The last interim call had a lot of discussion on SSI technologies = such as digital wallets, and how those fit with GNAP. I think it=E2=80=99s= worth continuing that conversation here on the list. There are a few = issues in the tracker that give some background, too: >>>=20 >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 = >>>=20 >>> There=E2=80=99s been a lot of interesting work recently in the = OpenID Foundation around using the Self-issued OP (SIOP) functionality = to bootstrap an SSI style login. This makes extensive use of the = implicit flow and front channel messaging, but minimization of the front = channel for message passing is a key design tenet of GNAP (so much so = that it=E2=80=99s included in our charter). Instead, GNAP has been built = around an idea that everything starts the same way: with an HTTP request = to the AS.=20 >>>=20 >>> The idea of an on-device AS has been brought up a lot, and we need = to consider if and how we want to deal with these kinds of use cases. = The most obvious way to address these would be to do some kind of clever = off-HTTP hack like SIOP, but keep in mind that even SIOP generally = starts off with an HTTP-based discovery call by the RP to make things = work. >>>=20 >>> My personal stance is that to do this, we need to re-evaluate our = assumptions about exactly what an AS does and what it needs to do those = things. In OAuth 2, it=E2=80=99s assumed that the AS is the device = that=E2=80=99s authenticating the user, collecting consent, managing the = client=E2=80=99s registration, and creating an access token based on = whatever set of rights that are associated with all of those things. In = UMA, this is turned around a bit by letting the RO present a bunch of = nebulous =E2=80=9Cclaims=E2=80=9D interactively, but still at the AS.=20 >>>=20 >>> With both of these, a key aspect remains: the AS needs to gather = necessary information, and issue the access token (or = identifiers/assertions). Because of how the protocol works, the client = software now has a better opportunity to present information to the AS, = either directly in the request or by introducing the AS to another = software component during the =E2=80=9Cinteraction=E2=80=9D phase. So, = what if we think of the AS primarily as a =E2=80=9Ctoken issuer=E2=80=9D?=20= >>>=20 >>> For example, if the client can present a verifiable credential (VC) = that represents the end user, the AS can validate that VC and make an = access token on behalf of that user, without having the user log in or = interact with the AS at all. This VC can contain whatever access rights = the token needs to represent, and the AS can translate that into an = artifact that the downstream RS=E2=80=99s can interpret, without having = to see the original VC or the user at all. The AS is still HTTP based, = but all the essential security and rights elements are provided by the = wallet. In this way, we can expand on the privacy-preserving aspects of = OAuth and bridge the worlds of SSI and web APIs without violating the = basic nature of either. >>>=20 >>> Coming from the OAuth world, it feels weird to issue tokens like = this, but there=E2=80=99s precedent for this kind of thing. Today, a = there are a number of service-based OAuth AS's that are told what claims = need to get put into the access token by some trusted component. All of = this happens outside the OAuth protocol. In GNAP, I think it makes sense = to account for this kind of thing in how we define the protocol. That = isn=E2=80=99t to say all of these pieces need to be defined in the core, = but the base protocol ought to be able to handle being extended in this = direction as needed. >>>=20 >>> I=E2=80=99m really interested to hear other people=E2=80=99s = thoughts on how this could come together. >>>=20 >>> =E2=80=94 Justin >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>> This communication, including any attachments, is confidential. If = you are not the intended recipient, you should not read it - please = contact me immediately, destroy it, and do not copy or use any part of = this communication or disclose anything about it. Thank you. Please note = that this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txaut= h&source=3Dgmail-imap&ust=3D1614379828000000&usg=3DAOvVaw3avsUGQ48fo1OUQV0= vyyKd = --Apple-Mail=_1650D36D-995D-47ED-B120-A04DDE8DDE64 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 An = important aspect in the discussion here, that I agree with, is that the = RS needs to be able to decide which AS it talks to. But inherent in that = is that it=E2=80=99s not the user=E2=80=99s decision, or the AS=E2=80=99s = decision, it=E2=80=99s the RS=E2=80=99s decision who it will trust to = get tokens from. And no matter what our philosophy, at the end of the = day the RS will always have the choice of whether to trust an inbound = request.

    Which is = why, to me, this really brings us to the question of what an AS = provides. The AS gives the RS a token that the RS decides to trust, and = that the RS can understand (either directly with something like JWT or = indirectly with something like introspection). But the AS also needs to = decide what to put INTO that token. As a consequence, the AS can get = that information from any number of places. The information could be = provided in a trusted way by the end user to the AS =E2=80=94 but this = does NOT necessarily mean that the AS belongs to the user or is under = their control. 

    Basically, I think we=E2=80=99re trying to hard to map the = OAuth general-concept of the RO having an account at the AS and logging = in to it before authorizing the request. I think that the call for = =E2=80=9Cevery user to have their own AS=E2=80=9D is such a huge = non-starter in so many domains that it hampers the solution space if = that=E2=80=99s what we presume. It=E2=80=99s up to the RS to decide who = it trusts, not the end user and not the RO. 
    I think we should ALLOW it, and we can = be clearer in GNAP that that=E2=80=99s one possible model, but not the = only one, and not even the general one. The AS manages all of the = information and interconnections needed to create an access token that = the RS will accept, and it is in charge of signaling to the RS what that = token=E2=80=99s good for. However, if the AS can learn through some = other means that a specific identified user has consented and provided = appropriate information in a trusted way, then THAT information can be = baked into the token by the AS. =E2=80=94 importantly, in a way that the = RS=E2=80=99s the AS protects can understand. 

    This last bit is where = general opacity of tokens is important here. There=E2=80=99s a natural = security boundary that arises from this model. What I=E2=80=99m = proposing here is just that we=E2=80=99re more explicit about what can = be put INTO that boundary. That=E2=80=99s where I=E2=80=99m seeing a lot = of this innovation in the SSI space fitting. You=E2=80=99re not coming = up with some universal access token that the RS will accept, but = you=E2=80=99re able to provide universal claims and artifacts that an AS = can process and translate into a token the RS will accept and do the = right thing with.

     =E2=80=94 Justin

    On Feb = 21, 2021, at 9:40 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    Hi Torsten,

    Thank you for raising = all of these excellent points. I hope we can all answer them and maybe = even add a section to the wiki. I'll start...

    You're right that OAuth deployments = almost exclusively put the AS and RS in the same domain. If OAuth were = adequate to today's needs we probably would not be here doing GNAP. = Since OAuth, we have increasing privacy concerns and security disasters. = GDPR, for example, separates the role of a data controller from a data = processor and treats them as separate legal entities. To oversimplify = GDPR, the data processor is spared privacy responsibility and = cost.

    You are = also right to mention open banking as a use-case. Open banking has not = adopted UMA 2.0 (on which I have worked for almost a decade) which is = based on OAuth. PSD2 and similar regulations do not tie the AS and RS to = the same security domain but they presume a narrow federation of = licensed (and regulated) ASs as payment processors for subjects to = choose among. This centralization to regulated fiduciaries is a privacy = trade-off that makes sense in banking. The fiduciary can be bonded so = they can refund the money to the subject in case of a security breach. = This privacy-security tradeoff does not make sense in healthcare and = other domains where the consequences of a breach are not easily = reversed.

    This = thread is about aligning GNAP and SSI. SSI does not abide = centralization, censorship, or surveillance. If GNAP makes any = assumptions that result in either a tight coupling between AS and RS = (surveillance) or even a federated fiduciary (centralization) we will = lose out on the benefits of progress in digital identity that is now = driving a lot of public-sector initiatives and starting to bleed over = into private sector practices. Zero Trust Architecture is an example and = OAuth is not well suited for ZTA.

    As you said, "technically, the = respective AS and RSs set up a trust relationship and agreed on ways to = share authorization and user data in order [to] enable secure API = access." This is where GNAP operates and we need to avoid _any_ = restrictions on either the AS or the RS being self-sovereign. Examples = of a self-sovereign RS could be a personal data store or an encrypted = data vault like the ones we work on in W3C/DIF. Any AS can be = self-sovereign if the subject controls all of the policies and these = policies are not shared, in the same way a private key is never not = shared. 

    Continuing your quote:
    I read your ideas regarding = self-sovereign ASs with great interest and got some = observations/questions:
    - A personal AS could certainly = control access to a person=E2=80=98s resources. I assume the person=E2=80=98= s RSs would only accept access tokens signed by the RO. Am I right?
    Yes, and. There is debate in = various SSI WGs whether a RS such as an Encrypted Data Vault should = respond to capabilities or tokens. Either way, the RO is in control of = the signature but a personal AS is a delegate of the RO (either directly = or via a mobile user agent). With capabilities such as ZCAP-LD or = biscuits, the token signature allows for filtered = delegation.

    - Do you envision this AS to be able to = control access to any kind of RS? How is the AS supposed to know what = authorization data this RS needs in order to perform access control = decisions? What data will be exchanged?
    Yes. The whole point, as far as I'm concerned, is to design = human centered standards. This is how W3C and IETF are different. Other = SDOs tend to be operated for institutional benefit. A person-centered AS = must work across institutional domains. 

    This, as you point out, brings up the = problem of scope. Ontologies and data models are, justifiably, = domain-specific. I, for example, work around the HL7 data model = standards and APIs like FHIR that are controlled by healthcare business = interests. It's unreasonable to expect a general solution to the data = model problem, although folks of the Linked Data persuasion might = disagree.

    Every = RS gets to decide what data models and ontologies it supports. These = decisions are public and sometimes standardized for the benefit of the = clients. A person's AS must read and maybe understand the RS data model = in order to issue tokens just like the client needs to do in order to = make a request to the AS. In our HIE of One Trustee project, we allow = the self-sovereign subject to inherit AS policies from self-sovereign = communities they choose and then modify the policies if they want. In = this way, communities compete for members on the basis of policy bundles = the same way churches compete for congregants.

    - How would this person delegate access = to her resources to someone else?
    There are two "persons" to consider. The RO delegates to an = RQ. But the RQ, in real life, is part of a team and often delegates to = associates. With or without capabilities, GNAP needs to deal with this = reality that RO and RQ user agents may be different from the client that = actually presents a token to the RS. Some of this difference = between user agents and clients we may be able to keep out of = band.

    - Are you aware of deployments = implementing this philosophy?
    Other than our HIE of One demonstration project in = healthcare, no. We started HIE of One before SSI in order to drive the = transition from UMA to UMA 2.0 and inform various healthcare = regulatory priorities. We then jumped on SSI immediately and added = it to the UMA 2 AS we call Trustee. Now we are trying to align SSI and = GNAP in order to enable human-centered protocols and zero-trust = architecture. 
     
    - What are the implications in terms of = user experience?
    Right now, the = human-centered user experience assumes a secure element and web browser = as user agents on a mobile device. Neither of these is readily = accessible as a server nor are they designed to accept code = plug-ins that represent the policies of an AS. One major exception is = people adding advertising and surveillance blockers like EFF Privacy = Badger to their browser. 

    The user experience implications of = having SSI data model standards and GNAP protocol standards is that = today's password managers (I have 250 RS relationships in mine) will = evolve to also control an AS agent. Just like I might register a W3C DID = with an RS instead of an email address, my policy manager might display = to me the token policies that will be applied by my AS to the personal = data I can control at that RS. 

    In some cases, my AS will allow me to = modify those policies just like the obnoxious cookie policy settings do = today. The BIG difference with GNAP is that I choose my AS separately = from the RS so the dark patterns associated with today's cookie policies = experience are no longer possible. GNAP means the RS exposes an API = rather than a UI.

    I've gone on far too long to address the issue of the AS as = an identity provider. It's fair to think of it that way. As it turns = out, in the SSI Secure Data Storage WG, we are debating the difference = between an Encrypted Data Vault and an Identity Hub. As far as I'm = concerned, the Identity Hub is mostly a GNAP AS. Join us on Thursdays at = 4 PM ET https://lists.identity.foundation/g/sds-wg/wiki/Home <= /div>

    Adrian



    On Sun, Feb = 21, 2021 at 4:34 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


    Am = 19.02.2021 um 23:50 schrieb Adrian Gropper <agropper@healthurl.com>:

    =EF=BB=BF
    I agree with = the first two of Justin's responses but not the last one.

    It's confusing to think = that there are more RS than AS.

    the OAuth deployments = I=E2=80=98m aware of typically have much more RSs than ASs. Why? Because = AS and a set of RSs belong to the same security domain (e.g. a certain = business) and it=E2=80=99s the AS=E2=80=99s responsibility to ensure = secure and convenient access to the APIs provided by this RSs. For = example: there is a AS controlling access to a cloud, streaming, and = messaging services of the same business. In case of open banking, the = bank=E2=80=98s AS is (on behalf of the user) authorizing access to APIs = for account information as well as payment initiation and potentially = other services. 

    Technically, the respective AS and RSs set up a trust = relationship and agreed on ways to share authorization and user data in = order enable secure API access.

    I read your ideas regarding = self-sovereign ASs with great interest and got some = observations/questions:
    - A personal AS could = certainly control access to a person=E2=80=98s resources. I assume the = person=E2=80=98s RSs would only accept access tokens signed by the RO. = Am I right?
    - Do you envision this AS to be able to = control access to any kind of RS? How is the AS supposed to know what = authorization data this RS needs in order to perform access control = decisions? What data will be exchanged?
    - How would = this person delegate access to her resources to someone else?
    - Are you aware of deployments implementing this = philosophy?
    - What are the implications in terms of = user experience?

    In my experience coupling between AS and RS is very tight. I = have a hard time to see how self-sovereign ASs would work. It feels like = such an AS in the end is an identity provider of some sort, which brings = me to what Justin proposed. I would assume using SSI credentials to = authenticate towards ASs is feasible and might have value but I=E2=80=98m = skeptical about the AS part.

    best regards,
    Torsten.

    =46rom a human-centered (and hopefully IETF) perspective, = each person might control or specify a different AS for each of their = personas or for each child or incompetent delegate of them as guardian. = We're familiar with separate gmail addresses for each persona.

    ASs will be = self-sovereign (as in SSI), fiduciary (as in a custodial bitcoin = wallet), or brokers (as in data brokers and surveillance capitalism). = Any RS that is willing to have a recurring relationship with a persona = could accept a GNAP AS endpoint instead of an email address. This is = easiest using HTTP, but GNAP need not exclude other RS / AS APIs and = transports. Designing around the uncensored specification of one's = AS as a human right would greatly simplify many aspects of GNAP = adoption.

    That = said, GNAP should not ignore the RS business or = jurisdictional reasons to limit the authority of the AS. UMA 2.0 = spent years dancing around this issue with ideas like "cascading" AS and = various centralized or federated AS concepts. My conclusion is that any = RS can always do whatever it wants and there's not much the = authorization protocol can help with other than specifying a = notification endpoint so that an RS can warn (and seek confirmation) or = log various exceptions. This turns out to be, after a year of testimony, = the regulation that applies to HIPAA RS APIs in the US. For this reason = GNAP might include a notification protocol in the AS specification, or = not.

    I propose = that embracing a self-sovereign agent is key to harmonizing the SSI and = GNAP standards.

    Adrian

    On Fri, Feb = 19, 2021 at 2:30 PM Justin Richer <jricher@mit.edu> wrote:
    Tobias, thanks for the great observations. Some reactions = inline below.

    On Feb 18, 2021, at 7:59 PM, = Tobias Looker <tobias.looker@mattr.global> = wrote:

    Justin,

    I think this is a great = and timely conversation to be having given the current interest around = SSI and efforts like SIOP, I have been doing quite a bit of work in this = space as of recent, so thought I'd add a few of the observations that = I've made.

    In my opinion SIOP was really a = bucket for solving quite a few different problems, not just one. In = particular I think its intent was to solve 3 major ones:
    1. Enabling portable identities
    2. Solving the = NASCAR problem
    3. Exploring different deployment models = for the provider

    To drill down briefly on = these, note much of my terminology is OpenID based due to SIOPs = origin 

    Enabling = portable identities - In general today in the case of OpenID, the = end-users identity as understood by a relying party is scoped within the = domain of the provider. Which means if that provider goes out of = business or for whatever reason decides to no longer offer the same = identity services to the End-User, their identity is essentially gone. = Whilst there has been some interesting related work from groups like = MODRNA on solutions to combat this like 'Account Porting', they often = assume the old provider remains online and willing to facilitate in the = account porting process so that the End-User can migrate to a new = provider. SIOP actually elected to do something different here by using = cryptography, instead of the End-User identifier being something like a = GUID asserted within the domain of the provider, SIOP defined this = instead as a public key fingerprint associated to a private key that's = assumed to be under the control of the user. In doing so the identity = itself becomes portable between providers by transferring the associated = private key. Now this approach does have drawbacks and arguably = encourages what many would refer to as bad cryptographic practise by not = allowing any way to do key rotation, however the idea was = there. 

    How GNAP can solve for this? By having flexibility around = how the resource owner / End-User is referred to by the Authorization = server (e.g allow the identifier to be something like a public key or a = resolvable identifier to public keys such as a DID)

    I personally think that GNAP should be = a flexible :carrier: of identifiers and other bits of identity = information. This is the main reason we went with the Subject = Identifiers draft from SECEVENT: it=E2=80=99s set up to talk about a = variety of different kinds of identifiers, all of them asserted in the = context of the AS. If there=E2=80=99s a definition for a DID URL or a = JWK in the sub_ids object structure, GNAP would be able to just use it = directly alongside every other format. I haven=E2=80=99t seen those = proposed yet, but it would be easy to do and, in my mind, would be a = better solution than the portable identifiers proposal that was recently = brought up in the FAPI working group in OIDF. (A side note, but the main = problem I have here is that it=E2=80=99s pasting semantics and formats = onto a field where none existed before, and that=E2=80=99s rife for = problems. Better to have a structure that takes that into account from = the start, in my view.)

    Solving the NASCAR problem - One of those = enduring problems in identity systems, which I think is really about the = three way negotiation going on between the RP, the End-User and the = Provider. SIOP's solution pushed for most of the power in this decision = making process to lie with the End-User, letting them decide who they = want as their provider rather than RP's providing an enumeration of who = they support via provider icons on their login page and End-Users having = to select from those options. It accomplished this via using a custom = URL scheme of `openid://` where the End-User would = register their chosen provider as a protocol handler for the `openid://` scheme. However, again as a solution it's not = without it's challenges, notably; only a single registration at a time = can be supported, the actual identity of the provider remains blind to = the RP until after the request is sent and it requires registration or = some form of default handling (e.g when there is no provider = registered).

    How GNAP can = solve for this? I actually don't think this is core to GNAP, there = may be some considerations around discovery that are worth paying = attention to but not much in the core protocol design.


    SIOP doesn=E2=80=99t really solve the = NASCAR issue since SIOP, by design, becomes yet one more login option = among many. I think GNAP can help this by enabling user-directed = provider discovery to kick off the process, but I agree that the core = protocol doesn=E2=80=99t really have much to say here, and = shouldn=E2=80=99t.

    Exploring different deployment models for the provider - = This is the most frequently talked about aspect of SIOP and perhaps the = most interesting to GNAP. I like to think about the scope of this issue = as designing to allow for either a partially or fully = distributed/decentralized provider, rather than a centralized one (e.g = an HTTP based AuthZ server). As you noted this does come with its = challenges many of which are technical in nature, i.e how to = appropriately address a decentralized provider and what protocols are = used to communicate with the provider.

    How GNAP can solve for this? I think that's what = much of the discussion on this thread will be about and whether there is = a hybrid model where some responsibility is still centrally administered = like token issuance, while allowing other aspects to occur in a more = distributed manner. Ideally though I'd like to see consideration for a = completely distributed model too.

    I agree that this seems = to be the most interesting place for overlap. I don=E2=80=99t actually = think the =E2=80=9Chybrid=E2=80=9D approach centralizes things. Instead, = you can think of the RS as having an associated AS, and that AS = accepting user consent and claims at runtime from a variety of sources = (wallets, VCs, etc.). In this way, we aren=E2=80=99t talking about a = single AS in the world handling all of these requests, we=E2=80=99re = talking about a distributed network of AS=E2=80=99s associated with an = even more widely distributed set of RS=E2=80=99s. SSI and its associated = technologies would help these =E2=80=9Clocal=E2=80=9D AS=E2=80=99s issue = access tokens without the RO needing to have an account, or even = necessarily directly interacting with the AS. There=E2=80=99s currently = a technology gap there, but my thoughts are that this is where the = changes to the interaction modes section can really come to = play. 

    I = think the notion of a non-HTTP AS is interesting, but I=E2=80=99m not = sure if that=E2=80=99s something GNAP ought to be solving for. I think = that there=E2=80=99s a deep value in building on top of HTTP for the = core protocol, and not abstracting away concepts from it. Otherwise, you = end up re-inventing layers, and you get something like SOAP all over = again. :)

     =E2=80=94 Justin


    Thanks,
    3D"Mattr 
    Tobias Looker
    Mattr
    +64 = (0) 27 378 0461
    tobias.looker@mattr.global
    3D"Mattr3D"Mattr3D"Mattr3D"Mattr

    This communication, including any attachments, is = confidential. If you are not the intended recipient, you should not read = it - please contact me immediately, destroy it, and do not copy or use = any part of this communication or disclose anything about it. Thank you. = Please note that this communication does not designate an information = system for the purposes of the Electronic Transactions Act = 2002.


    On Thu, Feb 18, 2021 at 9:19 PM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Justin,

    I agree that defining AS role primarily as a token issuer is = a fruitful idea. Solving this problem well would also respond to the = challenges discussed previously on the list. 

    Cheers
    Fabien 


    Le mer. 17 f=C3=A9vr. 2021 =C3=A0 = 23:27, Justin Richer <jricher@mit.edu> a =C3=A9crit :
    The last interim call had = a lot of discussion on SSI technologies such as digital wallets, and how = those fit with GNAP. I think it=E2=80=99s worth continuing that = conversation here on the list. There are a few issues in the tracker = that give some background, too:

    https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175

    There=E2=80=99s been a lot of interesting work recently in = the OpenID Foundation around using the Self-issued OP (SIOP) = functionality to bootstrap an SSI style login. This makes extensive use = of the implicit flow and front channel messaging, but minimization of = the front channel for message passing is a key design tenet of GNAP (so = much so that it=E2=80=99s included in our charter). Instead, GNAP has = been built around an idea that everything starts the same way: with an = HTTP request to the AS. 

    The idea of an on-device AS has been = brought up a lot, and we need to consider if and how we want to deal = with these kinds of use cases. The most obvious way to address these = would be to do some kind of clever off-HTTP hack like SIOP, but keep in = mind that even SIOP generally starts off with an HTTP-based discovery = call by the RP to make things work.

    My personal stance is that to do this, = we need to re-evaluate our assumptions about exactly what an AS does and = what it needs to do those things. In OAuth 2, it=E2=80=99s assumed that = the AS is the device that=E2=80=99s authenticating the user, collecting = consent, managing the client=E2=80=99s registration, and creating an = access token based on whatever set of rights that are associated with = all of those things. In UMA, this is turned around a bit by letting the = RO present a bunch of nebulous =E2=80=9Cclaims=E2=80=9D interactively, = but still at the AS. 

    With both of these, a key aspect remains: the AS needs to = gather necessary information, and issue the access token (or = identifiers/assertions). Because of how the protocol works, the client = software now has a better opportunity to present information to the AS, = either directly in the request or by introducing the AS to another = software component during the =E2=80=9Cinteraction=E2=80=9D phase. So, = what if we think of the AS primarily as a =E2=80=9Ctoken = issuer=E2=80=9D? 

    For example, if the client can present a verifiable = credential (VC) that represents the end user, the AS can validate that = VC and make an access token on behalf of that user, without having the = user log in or interact with the AS at all. This VC can contain whatever = access rights the token needs to represent, and the AS can translate = that into an artifact that the downstream RS=E2=80=99s can interpret, = without having to see the original VC or the user at all. The AS is = still HTTP based, but all the essential security and rights elements are = provided by the wallet. In this way, we can expand on the = privacy-preserving aspects of OAuth and bridge the worlds of SSI and web = APIs without violating the basic nature of either.

    Coming from the OAuth = world, it feels weird to issue tokens like this, but there=E2=80=99s = precedent for this kind of thing. Today, a there are a number of = service-based OAuth AS's that are told what claims need to get put into = the access token by some trusted component. All of this happens outside = the OAuth protocol. In GNAP, I think it makes sense to account for this = kind of thing in how we define the protocol. That isn=E2=80=99t to say = all of these pieces need to be defined in the core, but the base = protocol ought to be able to handle being extended in this direction as = needed.

    I=E2=80=99= m really interested to hear other people=E2=80=99s thoughts on how this = could come together.

     =E2=80=94 Justin
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    = 

    This communication, including any attachments, is =
confidential. If you are not the intended recipient, you should not read =
it - please contact me immediately, destroy it, and do not copy or use =
any part of this communication or disclose anything about it. Thank you. =
Please note that this communication does not designate an information =
system for the purposes of the Electronic Transactions Act =
2002.

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    = --
    TXAuth = mailing list
    TXAuth@ietf.org
    https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/lis= tinfo/txauth&source=3Dgmail-imap&ust=3D1614379828000000&usg=3D= AOvVaw3avsUGQ48fo1OUQV0vyyKd

    = --Apple-Mail=_1650D36D-995D-47ED-B120-A04DDE8DDE64-- From nobody Tue Feb 23 04:51:30 2021 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 9947E3A2826 for ; Tue, 23 Feb 2021 04:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, KHOP_HELO_FCRDNS=0.4, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 7e8gqdWJh3sV for ; Tue, 23 Feb 2021 04:51:24 -0800 (PST) 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 0533F3A142C for ; Tue, 23 Feb 2021 04:51:22 -0800 (PST) Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d14 with ME id YcrD2400Q4zJUWJ03crDwk; Tue, 23 Feb 2021 13:51:21 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 23 Feb 2021 13:51:21 +0100 X-ME-IP: 90.79.53.231 To: Justin Richer , txauth gnap References: <4EAA60A4-4800-400F-A70A-F7B7F1A6CB0A@mit.edu> From: Denis Message-ID: <73cd4e8b-c843-ab87-c640-eea763b6002a@free.fr> Date: Tue, 23 Feb 2021 13:51:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <4EAA60A4-4800-400F-A70A-F7B7F1A6CB0A@mit.edu> Content-Type: multipart/alternative; boundary="------------C34E848C58BACC2A73162655" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 12:51:30 -0000 This is a multi-part message in MIME format. --------------C34E848C58BACC2A73162655 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi  Justin, See my comments between the lines. > An important aspect in the discussion here, that I agree with, is that > the RS needs to be able to decide _/which AS it talks to/_.  While I would agree with such a sentence in the OAuth WG, I don't believe that this sentence is applicable in general in the context of GNAP. A RS does not need to "talk to" any AS. A RS decides which AS(s) it trusts to issue access tokens *that contains some set of privileges*. > But inherent in that is that it’s not the user’s decision, or the AS’s > decision, it’s the RS’s decision who it will trust to get tokens from. A RS does not necessarily need to trust all the access tokens issued by a given AS, but only access tokens from a given AS that contain *a given set of privileges*. > And no matter what our philosophy, at the end of the day the RS will > always have the choice of whether to trust an inbound request. Not exactly: the RS will apply the rules given by the RO. > Which is why, to me, this really brings us to the question of what an > AS provides. The AS gives the RS a token that the RS decides to trust, > and that the RS can understand (either directly with something like > JWT or indirectly with something like introspection). > But the AS also needs to decide what to put INTO that token. As a > consequence, the AS can get that information from any number of places. > The information could be provided in a trusted way by the end user to > the AS — but this does NOT necessarily mean that the AS belongs > to the user or is under their control. > > Basically, I think we’re trying to hard to map the OAuth > general-concept of the RO having an account at the AS and logging in > to it before authorizing the request. > I think that the call for “every user to have their own AS” is such a > huge non-starter in so many domains that it hampers the solution space > if that’s what we presume. > It’s up to the RS to decide who it trusts, not the end user and not > the RO. > > I think we should ALLOW it, and we can be clearer in GNAP that that’s > one possible model, but not the only one, and not even the general one. > The AS manages all of the information and interconnections needed to > create an access token that the RS will accept, and it is in charge of > signaling to the RS what that token’s good for. I disagree: the AS is NOT in charge of signaling to the RS what that token’s good for. It is up to the RS to decide which privileges it will accept among all the privileges included into an access token. > However, if the AS can learn through some other means that a specific > identified user has consented and provided appropriate information in > a trusted way, > then THAT information can be baked into the token by the AS. — > importantly,_/in a way that the RS’s the AS protects can understand/_. I disagree: Trust relationships are not bilateral but only unilateral. An AS does not need to have any specific prior relationship with a given RS. It is up to the RS(s) to decide which AS_*(s)*_ it trust(s) *and for which privileges*. > This last bit is where general _/opacity of tokens/_ is important > here. There’s a natural security boundary that arises from this model. > What I’m proposing here is just that we’re more explicit about what > can be put INTO that boundary. That’s where I’m seeing a lot of this > innovation in the SSI space fitting. You’re not coming up with some > universal access token that the RS will accept, but you’re able to > provide universal claims and artifacts that an AS can process and > /_translate into a token the RS will accept and do the right thing with_/. Your argumentation about token opacity is making the assumption that the AS and the RS need to have a prior relationship before any access can take place. While this was valid with OAuth, this is no more valid in the context of GNAP.  The client should be able to inform the AS about the access token format(s) acceptable to the RS. Then the client may indicate to the AS these acceptable formats. If the RS and the AS have an access token format in common, then the process may continue. When only attributes (i.e. not rights) are being requested to an AS by the client, the client does not need to disclose the identity of the RS to the AS, which has the major advantage to prevent the AS to act as Big Brother. _Note_: this does not preclude the use of rights, in particular in the context of a single organization or enterprise. Denis > >  — Justin > >> On Feb 21, 2021, at 9:40 AM, Adrian Gropper > > wrote: >> >> Hi Torsten, >> >> Thank you for raising all of these excellent points. I hope we can >> all answer them and maybe even add a section to the wiki. I'll start... >> >> You're right that OAuth deployments almost exclusively put the AS and >> RS in the same domain. If OAuth were adequate to today's needs we >> probably would not be here doing GNAP. Since OAuth, we have >> increasing privacy concerns and security disasters. GDPR, for >> example, separates the role of a data controller from a data >> processor and treats them as separate legal entities. To oversimplify >> GDPR, the data processor is spared privacy responsibility and cost. >> >> You are also right to mention open banking as a use-case. Open >> banking has not adopted UMA 2.0 (on which I have worked for almost a >> decade) which is based on OAuth. PSD2 and similar regulations do not >> tie the AS and RS to the same security domain but they presume a >> narrow federation of licensed (and regulated) ASs as payment >> processors for subjects to choose among. This centralization to >> regulated fiduciaries is a privacy trade-off that makes sense in >> banking. The fiduciary can be bonded so they can refund the money to >> the subject in case of a security breach. This privacy-security >> tradeoff does not make sense in healthcare and other domains where >> the consequences of a breach are not easily reversed. >> >> This thread is about aligning GNAP and SSI. SSI does not abide >> centralization, censorship, or surveillance. If GNAP makes any >> assumptions that result in either a tight coupling between AS and RS >> (surveillance) or even a federated fiduciary (centralization) we will >> lose out on the benefits of progress in digital identity that is now >> driving a lot of public-sector initiatives and starting to bleed over >> into private sector practices. Zero Trust Architecture is an example >> and OAuth is not well suited for ZTA. >> >> As you said, "technically, the respective AS and RSs set up a trust >> relationship and agreed on ways to share authorization and user data >> in order [to] enable secure API access." This is where GNAP operates >> and we need to avoid _any_ restrictions on either the AS or the RS >> being self-sovereign. Examples of a self-sovereign RS could be a >> personal data store or an encrypted data vault like the ones we work >> on in W3C/DIF. Any AS can be self-sovereign if the subject controls >> all of the policies and these policies are not shared, in the same >> way a private key is never not shared. >> >> Continuing your quote: >> >> I read your ideas regarding self-sovereign ASs with great >> interest and got some observations/questions: >> - A personal AS could certainly control access to a person‘s >> resources. I assume the person‘s RSs would only accept access >> tokens signed by the RO. Am I right? >> >> Yes, and. There is debate in various SSI WGs whether a RS such as an >> Encrypted Data Vault should respond to capabilities or tokens. Either >> way, the RO is in control of the signature but a personal AS is a >> delegate of the RO (either directly or via a mobile user agent). With >> capabilities such as ZCAP-LD or biscuits, the token signature allows >> for filtered delegation. >> >> - Do you envision this AS to be able to control access to any >> kind of RS? How is the AS supposed to know what authorization >> data this RS needs in order to perform access control decisions? >> What data will be exchanged? >> >> Yes. The whole point, as far as I'm concerned, is to design human >> centered standards. This is how W3C and IETF are different. Other >> SDOs tend to be operated for institutional benefit. A person-centered >> AS must work across institutional domains. >> >> This, as you point out, brings up the problem of scope. Ontologies >> and data models are, justifiably, domain-specific. I, for example, >> work around the HL7 data model standards and APIs like FHIR that are >> controlled by healthcare business interests. It's unreasonable to >> expect a general solution to the data model problem, although folks >> of the Linked Data persuasion might disagree. >> >> Every RS gets to decide what data models and ontologies it supports. >> These decisions are public and sometimes standardized for the benefit >> of the clients. A person's AS must read and maybe understand the RS >> data model in order to issue tokens just like the client needs to do >> in order to make a request to the AS. In our HIE of One Trustee >> project, we allow the self-sovereign subject to inherit AS policies >> from self-sovereign communities they choose and then modify the >> policies if they want. In this way, communities compete for members >> on the basis of policy bundles the same way churches compete for >> congregants. >> >> - How would this person delegate access to her resources to >> someone else? >> >> There are two "persons" to consider. The RO delegates to an RQ. But >> the RQ, in real life, is part of a team and often delegates to >> associates. With or without capabilities, GNAP needs to deal with >> this reality that RO and RQ user agents may be different from the >> client that actually presents a token to the RS. Some of this >> difference between user agents and clients we may be able to keep out >> of band. >> >> - Are you aware of deployments implementing this philosophy? >> >> Other than our HIE of One demonstration project in healthcare, no. We >> started HIE of One before SSI in order to drive the transition from >> UMA to UMA 2.0 and inform various healthcare regulatory priorities. >> We then jumped on SSI immediately and added it to the UMA 2 AS we >> call Trustee. Now we are trying to align SSI and GNAP in order to >> enable human-centered protocols and zero-trust architecture. >> >> - What are the implications in terms of user experience? >> >> Right now, the human-centered user experience assumes a secure >> element and web browser as user agents on a mobile device. Neither of >> these is readily accessible as a server nor are they designed to >> accept code plug-ins that represent the policies of an AS. One major >> exception is people adding advertising and surveillance blockers like >> EFF Privacy Badger to their browser. >> >> The user experience implications of having SSI data model standards >> and GNAP protocol standards is that today's password managers (I have >> 250 RS relationships in mine) will evolve to also control an AS >> agent. Just like I might register a W3C DID with an RS instead of an >> email address, my policy manager might display to me the token >> policies that will be applied by my AS to the personal data I can >> control at that RS. >> >> In some cases, my AS will allow me to modify those policies just like >> the obnoxious cookie policy settings do today. The BIG difference >> with GNAP is that I choose my AS separately from the RS so the dark >> patterns associated with today's cookie policies experience are no >> longer possible. GNAP means the RS exposes an API rather than a UI. >> >> I've gone on far too long to address the issue of the AS as an >> identity provider. It's fair to think of it that way. As it turns >> out, in the SSI Secure Data Storage WG, we are debating the >> difference between an Encrypted Data Vault and an Identity Hub. As >> far as I'm concerned, the Identity Hub is mostly a GNAP AS. Join us >> on Thursdays at 4 PM ET >> https://lists.identity.foundation/g/sds-wg/wiki/Home >> >> >> Adrian >> >> >> >> On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt >> > wrote: >> >> >> >>> Am 19.02.2021 um 23:50 schrieb Adrian Gropper >>> >: >>> >>>  >>> I agree with the first two of Justin's responses but not the >>> last one. >>> >>> It's confusing to think that there are more RS than AS. >> >> the OAuth deployments I‘m aware of typically have much more RSs >> than ASs. Why? Because AS and a set of RSs belong to the same >> security domain (e.g. a certain business) and it’s the AS’s >> responsibility to ensure secure and convenient access to the APIs >> provided by this RSs. For example: there is a AS controlling >> access to a cloud, streaming, and messaging services of the same >> business. In case of open banking, the bank‘s AS is (on behalf of >> the user) authorizing access to APIs for account information as >> well as payment initiation and potentially other services. >> >> Technically, the respective AS and RSs set up a trust >> relationship and agreed on ways to share authorization and user >> data in order enable secure API access. >> >> I read your ideas regarding self-sovereign ASs with great >> interest and got some observations/questions: >> - A personal AS could certainly control access to a person‘s >> resources. I assume the person‘s RSs would only accept access >> tokens signed by the RO. Am I right? >> - Do you envision this AS to be able to control access to any >> kind of RS? How is the AS supposed to know what authorization >> data this RS needs in order to perform access control decisions? >> What data will be exchanged? >> - How would this person delegate access to her resources to >> someone else? >> - Are you aware of deployments implementing this philosophy? >> - What are the implications in terms of user experience? >> >> In my experience coupling between AS and RS is very tight. I have >> a hard time to see how self-sovereign ASs would work. It feels >> like such an AS in the end is an identity provider of some sort, >> which brings me to what Justin proposed. I would assume using SSI >> credentials to authenticate towards ASs is feasible and might >> have value but I‘m skeptical about the AS part. >> >> best regards, >> Torsten. >> >>> From a human-centered (and hopefully IETF) perspective, each >>> person might control or specify a different AS for each of their >>> personas or for each child or incompetent delegate of them as >>> guardian. We're familiar with separate gmail addresses for each >>> persona. >>> >>> ASs will be self-sovereign (as in SSI), fiduciary (as in a >>> custodial bitcoin wallet), or brokers (as in data brokers and >>> surveillance capitalism). Any RS that is willing to have a >>> recurring relationship with a persona could accept a GNAP AS >>> endpoint instead of an email address. This is easiest using >>> HTTP, but GNAP need not exclude other RS / AS APIs and >>> transports. Designing around the uncensored specification of >>> one's AS as a human right would greatly simplify many aspects of >>> GNAP adoption. >>> >>> That said, GNAP should not ignore the RS business or >>> jurisdictional reasons to limit the authority of the AS. UMA 2.0 >>> spent years dancing around this issue with ideas like >>> "cascading" AS and various centralized or federated AS concepts. >>> My conclusion is that any RS can always do whatever it wants and >>> there's not much the authorization protocol can help with other >>> than specifying a notification endpoint so that an RS can warn >>> (and seek confirmation) or log various exceptions. This turns >>> out to be, after a year of testimony, the regulation that >>> applies to HIPAA RS APIs in the US. For this reason GNAP might >>> include a notification protocol in the AS specification, or not. >>> >>> I propose that embracing a self-sovereign agent is key to >>> harmonizing the SSI and GNAP standards. >>> >>> Adrian >>> >>> On Fri, Feb 19, 2021 at 2:30 PM Justin Richer >> > wrote: >>> >>> Tobias, thanks for the great observations. Some reactions >>> inline below. >>> >>>> On Feb 18, 2021, at 7:59 PM, Tobias Looker >>>> >>> > wrote: >>>> >>>> Justin, >>>> >>>> I think this is a great and timely conversation to be >>>> having given the current interest around SSI and efforts >>>> like SIOP, I have been doing quite a bit of work in this >>>> space as of recent, so thought I'd add a few of the >>>> observations that I've made. >>>> >>>> In my opinion SIOP was really a bucket for solving quite a >>>> few different problems, not just one. In particular I think >>>> its intent was to solve 3 major ones: >>>> >>>> 1. Enabling portable identities >>>> 2. Solving the NASCAR problem >>>> 3. Exploring different deployment models for the provider >>>> >>>> To drill down briefly on these, note much of my terminology >>>> is OpenID based due to SIOPs origin >>>> >>>> *Enabling portable identities *- In general today in the >>>> case of OpenID, the end-users identity as understood by a >>>> relying party is scoped within the domain of the provider. >>>> Which means if that provider goes out of business or for >>>> whatever reason decides to no longer offer the same >>>> identity services to the End-User, their identity is >>>> essentially gone. Whilst there has been some interesting >>>> related work from groups like MODRNA on solutions to combat >>>> this like 'Account Porting', they often assume the old >>>> provider remains online and willing to facilitate in the >>>> account porting process so that the End-User can migrate to >>>> a new provider. SIOP actually elected to do something >>>> different here by using cryptography, instead of the >>>> End-User identifier being something like a GUID asserted >>>> within the domain of the provider, SIOP defined this >>>> instead as a public key fingerprint associated to a private >>>> key that's assumed to be under the control of the user. In >>>> doing so the identity itself becomes portable between >>>> providers by transferring the associated private key. Now >>>> this approach does have drawbacks and arguably encourages >>>> what many would refer to as bad cryptographic practise by >>>> not allowing any way to do key rotation, however the idea >>>> was there. >>>> >>>> *How GNAP can solve for this?* By having flexibility around >>>> how the resource owner / End-User is referred to by the >>>> Authorization server (e.g allow the identifier to be >>>> something like a public key or a resolvable identifier to >>>> public keys such as a DID) >>> >>> I personally think that GNAP should be a flexible :carrier: >>> of identifiers and other bits of identity information. This >>> is the main reason we went with the Subject Identifiers >>> draft from SECEVENT: it’s set up to talk about a variety of >>> different kinds of identifiers, all of them asserted in the >>> context of the AS. If there’s a definition for a DID URL or >>> a JWK in the sub_ids object structure, GNAP would be able to >>> just use it directly alongside every other format. I haven’t >>> seen those proposed yet, but it would be easy to do and, in >>> my mind, would be a better solution than the portable >>> identifiers proposal that was recently brought up in the >>> FAPI working group in OIDF. (A side note, but the main >>> problem I have here is that it’s pasting semantics and >>> formats onto a field where none existed before, and that’s >>> rife for problems. Better to have a structure that takes >>> that into account from the start, in my view.) >>> >>>> >>>> *Solving the NASCAR problem *- One of those enduring >>>> problems in identity systems, which I think is really about >>>> the three way negotiation going on between the RP, the >>>> End-User and the Provider. SIOP's solution pushed for most >>>> of the power in this decision making process to lie with >>>> the End-User, letting them decide who they want as their >>>> provider rather than RP's providing an enumeration of who >>>> they support via provider icons on their login page and >>>> End-Users having to select from those options. It >>>> accomplished this via using a custom URL scheme of >>>> `openid://` where the End-User would register their chosen >>>> provider as a protocol handler for the `openid://` scheme. >>>> However, again as a solution it's not without it's >>>> challenges, notably; only a single registration at a time >>>> can be supported, the actual identity of the provider >>>> remains blind to the RP until after the request is sent and >>>> it requires registration or some form of default handling >>>> (e.g when there is no provider registered). >>>> >>>> *How GNAP can solve for this?* I actually don't think this >>>> is core to GNAP, there may be some considerations around >>>> discovery that are worth paying attention to but not much >>>> in the core protocol design. >>>> >>> >>> SIOP doesn’t really solve the NASCAR issue since SIOP, by >>> design, becomes yet one more login option among many. I >>> think GNAP can help this by enabling user-directed provider >>> discovery to kick off the process, but I agree that the core >>> protocol doesn’t really have much to say here, and shouldn’t. >>> >>>> *Exploring different deployment models for the provider* - >>>> This is the most frequently talked about aspect of SIOP and >>>> perhaps the most interesting to GNAP. I like to think about >>>> the scope of this issue as designing to allow for either a >>>> partially or fully distributed/decentralized provider, >>>> rather than a centralized one (e.g an HTTP based AuthZ >>>> server). As you noted this does come with its challenges >>>> many of which are technical in nature, i.e how to >>>> appropriately address a decentralized provider and what >>>> protocols are used to communicate with the provider. >>>> >>>> *How GNAP can solve for this?* I think that's what much of >>>> the discussion on this thread will be about and whether >>>> there is a hybrid model where some responsibility is still >>>> centrally administered like token issuance, while allowing >>>> other aspects to occur in a more distributed manner. >>>> Ideally though I'd like to see consideration for a >>>> completely distributed model too. >>> >>> I agree that this seems to be the most interesting place for >>> overlap. I don’t actually think the “hybrid” approach >>> centralizes things. Instead, you can think of the RS as >>> having an associated AS, and that AS accepting user consent >>> and claims at runtime from a variety of sources (wallets, >>> VCs, etc.). In this way, we aren’t talking about a single AS >>> in the world handling all of these requests, we’re talking >>> about a distributed network of AS’s associated with an even >>> more widely distributed set of RS’s. SSI and its associated >>> technologies would help these “local” AS’s issue access >>> tokens without the RO needing to have an account, or even >>> necessarily directly interacting with the AS. There’s >>> currently a technology gap there, but my thoughts are that >>> this is where the changes to the interaction modes section >>> can really come to play. >>> >>> I think the notion of a non-HTTP AS is interesting, but I’m >>> not sure if that’s something GNAP ought to be solving for. I >>> think that there’s a deep value in building on top of HTTP >>> for the core protocol, and not abstracting away concepts >>> from it. Otherwise, you end up re-inventing layers, and you >>> get something like SOAP all over again. :) >>> >>>  — Justin >>> >>>> >>>> Thanks, >>>> Mattr website >>>> >>>> >>>> *Tobias Looker* >>>> Mattr >>>> +64 (0) 27 378 0461 >>>> tobias.looker@mattr.global >>>> Mattr website >>>> >>>> Mattr on LinkedIn >>>> >>>> Mattr on Twitter >>>> >>>> Mattr on Github >>>> >>>> >>>> >>>> >>>> This communication, including any attachments, is >>>> confidential. If you are not the intended recipient, you >>>> should not read it - please contact me immediately, destroy >>>> it, and do not copy or use any part of this communication >>>> or disclose anything about it. Thank you. Please note that >>>> this communication does not designate an information system >>>> for the purposes of the Electronic Transactions Act 2002. >>>> >>>> >>>> On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault >>>> >>> > wrote: >>>> >>>> Hi Justin, >>>> >>>> I agree that defining AS role primarily as a token >>>> issuer is a fruitful idea. Solving this problem well >>>> would also respond to the challenges discussed >>>> previously on the list. >>>> >>>> Cheers >>>> Fabien >>>> >>>> >>>> Le mer. 17 févr. 2021 à 23:27, Justin Richer >>>> > a écrit : >>>> >>>> The last interim call had a lot of discussion on >>>> SSI technologies such as digital wallets, and how >>>> those fit with GNAP. I think it’s worth continuing >>>> that conversation here on the list. There are a few >>>> issues in the tracker that give some background, too: >>>> >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 >>>> >>>> >>>> There’s been a lot of interesting work recently in >>>> the OpenID Foundation around using the Self-issued >>>> OP (SIOP) functionality to bootstrap an SSI style >>>> login. This makes extensive use of the implicit >>>> flow and front channel messaging, but minimization >>>> of the front channel for message passing is a key >>>> design tenet of GNAP (so much so that it’s included >>>> in our charter). Instead, GNAP has been built >>>> around an idea that everything starts the same way: >>>> with an HTTP request to the AS. >>>> >>>> The idea of an on-device AS has been brought up a >>>> lot, and we need to consider if and how we want to >>>> deal with these kinds of use cases. The most >>>> obvious way to address these would be to do some >>>> kind of clever off-HTTP hack like SIOP, but keep in >>>> mind that even SIOP generally starts off with an >>>> HTTP-based discovery call by the RP to make things >>>> work. >>>> >>>> My personal stance is that to do this, we need to >>>> re-evaluate our assumptions about exactly what an >>>> AS does and what it needs to do those things. In >>>> OAuth 2, it’s assumed that the AS is the device >>>> that’s authenticating the user, collecting consent, >>>> managing the client’s registration, and creating an >>>> access token based on whatever set of rights that >>>> are associated with all of those things. In UMA, >>>> this is turned around a bit by letting the RO >>>> present a bunch of nebulous “claims” interactively, >>>> but still at the AS. >>>> >>>> With both of these, a key aspect remains: the AS >>>> needs to gather necessary information, and issue >>>> the access token (or identifiers/assertions). >>>> Because of how the protocol works, the client >>>> software now has a better opportunity to present >>>> information to the AS, either directly in the >>>> request or by introducing the AS to another >>>> software component during the “interaction” phase. >>>> So, what if we think of the AS primarily as a >>>> “token issuer”? >>>> >>>> For example, if the client can present a verifiable >>>> credential (VC) that represents the end user, the >>>> AS can validate that VC and make an access token on >>>> behalf of that user, without having the user log in >>>> or interact with the AS at all. This VC can contain >>>> whatever access rights the token needs to >>>> represent, and the AS can translate that into an >>>> artifact that the downstream RS’s can interpret, >>>> without having to see the original VC or the user >>>> at all. The AS is still HTTP based, but all the >>>> essential security and rights elements are provided >>>> by the wallet. In this way, we can expand on the >>>> privacy-preserving aspects of OAuth and bridge the >>>> worlds of SSI and web APIs without violating the >>>> basic nature of either. >>>> >>>> Coming from the OAuth world, it feels weird to >>>> issue tokens like this, but there’s precedent for >>>> this kind of thing. Today, a there are a number of >>>> service-based OAuth AS's that are told what claims >>>> need to get put into the access token by some >>>> trusted component. All of this happens outside the >>>> OAuth protocol. In GNAP, I think it makes sense to >>>> account for this kind of thing in how we define the >>>> protocol. That isn’t to say all of these pieces >>>> need to be defined in the core, but the base >>>> protocol ought to be able to handle being extended >>>> in this direction as needed. >>>> >>>> I’m really interested to hear other people’s >>>> thoughts on how this could come together. >>>> >>>>  — Justin >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> >>>> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3avsUGQ48fo1OUQV0vyyKd >>> >> > > --------------C34E848C58BACC2A73162655 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    Hi  Justin,

    See my comments between the lines.
    An important aspect in the discussion here, that I agree with, is that the RS needs to be able to decide which AS it talks to.

     While I would agree with such a sentence in the OAuth WG, I don't believe that this sentence is applicable in general in the context of GNAP.
    A RS does not need to "talk to" any AS. A RS decides which AS(s) it trusts to issue access tokens that contains some set of privileges.

    But inherent in that is that it’s not the user’s decision, or the AS’s decision, it’s the RS’s decision who it will trust to get tokens from.

    A RS does not necessarily need to trust all the access tokens issued by a given AS, but only access tokens from a given AS that contain
    a given set of privileges.

    And no matter what our philosophy, at the end of the day the RS will always have the choice of whether to trust an inbound request.

    Not exactly: the RS will apply the rules given by the RO.

    Which is why, to me, this really brings us to the question of what an AS provides. The AS gives the RS a token that the RS decides to trust,
    and that the RS can understand (either directly with something like JWT or indirectly with something like introspection).
    But the AS also needs to decide what to put INTO that token. As a consequence, the AS can get that information from any number of places.
    The information could be provided in a trusted way by the end user to the AS — but this does NOT necessarily mean that the AS belongs
    to the user or is under their control. 

    Basically, I think we’re trying to hard to map the OAuth general-concept of the RO having an account at the AS and logging in to it before authorizing the request.
    I think that the call for “every user to have their own AS” is such a huge non-starter in so many domains that it hampers the solution space if that’s what we presume.
    It’s up to the RS to decide who it trusts, not the end user and not the RO. 

    I think we should ALLOW it, and we can be clearer in GNAP that that’s one possible model, but not the only one, and not even the general one.
    The AS manages all of the information and interconnections needed to create an access token that the RS will accept, and it is in charge of signaling to the RS what that token’s good for.

    I disagree: the AS is NOT in charge of signaling to the RS what that token’s good for. It is up to the RS to decide which privileges it will accept
    among all the privileges included into an access token.

    However, if the AS can learn through some other means that a specific identified user has consented and provided appropriate information in a trusted way,
    then THAT information can be baked into the token by the AS. — importantly, in a way that the RS’s the AS protects can understand.

    I disagree: Trust relationships are not bilateral but only unilateral. An AS does not need to have any specific prior relationship with a given RS.
    It is up to the RS(s) to decide which AS(s) it trust(s) and for which privileges.

    This last bit is where general opacity of tokens is important here. There’s a natural security boundary that arises from this model. What I’m proposing here is just that we’re more explicit about what can be put INTO that boundary. That’s where I’m seeing a lot of this innovation in the SSI space fitting. You’re not coming up with some universal access token that the RS will accept, but you’re able to provide universal claims and artifacts that an AS can process and translate into a token the RS will accept and do the right thing with.

    Your argumentation about token opacity is making the assumption that the AS and the RS need to have a prior relationship before any access can take place.
    While this was valid with OAuth, this is no more valid in the context of GNAP.  The client should be able to inform the AS about the access token format(s) acceptable to the RS.
    Then the client may indicate to the AS these acceptable formats. If the RS and the AS have an access token format in common, then the process may continue.

    When only attributes (i.e. not rights) are being requested to an AS by the client, the client does not need to disclose the identity of the RS to the AS,
    which has the major advantage to prevent the AS to act as Big Brother.

        Note: this does not preclude the use of rights, in particular in the context of a single organization or enterprise.

    Denis


     — Justin

    On Feb 21, 2021, at 9:40 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    Hi Torsten,

    Thank you for raising all of these excellent points. I hope we can all answer them and maybe even add a section to the wiki. I'll start...

    You're right that OAuth deployments almost exclusively put the AS and RS in the same domain. If OAuth were adequate to today's needs we probably would not be here doing GNAP. Since OAuth, we have increasing privacy concerns and security disasters. GDPR, for example, separates the role of a data controller from a data processor and treats them as separate legal entities. To oversimplify GDPR, the data processor is spared privacy responsibility and cost.

    You are also right to mention open banking as a use-case. Open banking has not adopted UMA 2.0 (on which I have worked for almost a decade) which is based on OAuth. PSD2 and similar regulations do not tie the AS and RS to the same security domain but they presume a narrow federation of licensed (and regulated) ASs as payment processors for subjects to choose among. This centralization to regulated fiduciaries is a privacy trade-off that makes sense in banking. The fiduciary can be bonded so they can refund the money to the subject in case of a security breach. This privacy-security tradeoff does not make sense in healthcare and other domains where the consequences of a breach are not easily reversed.

    This thread is about aligning GNAP and SSI. SSI does not abide centralization, censorship, or surveillance. If GNAP makes any assumptions that result in either a tight coupling between AS and RS (surveillance) or even a federated fiduciary (centralization) we will lose out on the benefits of progress in digital identity that is now driving a lot of public-sector initiatives and starting to bleed over into private sector practices. Zero Trust Architecture is an example and OAuth is not well suited for ZTA.

    As you said, "technically, the respective AS and RSs set up a trust relationship and agreed on ways to share authorization and user data in order [to] enable secure API access." This is where GNAP operates and we need to avoid _any_ restrictions on either the AS or the RS being self-sovereign. Examples of a self-sovereign RS could be a personal data store or an encrypted data vault like the ones we work on in W3C/DIF. Any AS can be self-sovereign if the subject controls all of the policies and these policies are not shared, in the same way a private key is never not shared. 

    Continuing your quote:
    I read your ideas regarding self-sovereign ASs with great interest and got some observations/questions:
    - A personal AS could certainly control access to a person‘s resources. I assume the person‘s RSs would only accept access tokens signed by the RO. Am I right?
    Yes, and. There is debate in various SSI WGs whether a RS such as an Encrypted Data Vault should respond to capabilities or tokens. Either way, the RO is in control of the signature but a personal AS is a delegate of the RO (either directly or via a mobile user agent). With capabilities such as ZCAP-LD or biscuits, the token signature allows for filtered delegation.

    - Do you envision this AS to be able to control access to any kind of RS? How is the AS supposed to know what authorization data this RS needs in order to perform access control decisions? What data will be exchanged?
    Yes. The whole point, as far as I'm concerned, is to design human centered standards. This is how W3C and IETF are different. Other SDOs tend to be operated for institutional benefit. A person-centered AS must work across institutional domains. 

    This, as you point out, brings up the problem of scope. Ontologies and data models are, justifiably, domain-specific. I, for example, work around the HL7 data model standards and APIs like FHIR that are controlled by healthcare business interests. It's unreasonable to expect a general solution to the data model problem, although folks of the Linked Data persuasion might disagree.

    Every RS gets to decide what data models and ontologies it supports. These decisions are public and sometimes standardized for the benefit of the clients. A person's AS must read and maybe understand the RS data model in order to issue tokens just like the client needs to do in order to make a request to the AS. In our HIE of One Trustee project, we allow the self-sovereign subject to inherit AS policies from self-sovereign communities they choose and then modify the policies if they want. In this way, communities compete for members on the basis of policy bundles the same way churches compete for congregants.

    - How would this person delegate access to her resources to someone else?
    There are two "persons" to consider. The RO delegates to an RQ. But the RQ, in real life, is part of a team and often delegates to associates. With or without capabilities, GNAP needs to deal with this reality that RO and RQ user agents may be different from the client that actually presents a token to the RS. Some of this difference between user agents and clients we may be able to keep out of band.

    - Are you aware of deployments implementing this philosophy?
    Other than our HIE of One demonstration project in healthcare, no. We started HIE of One before SSI in order to drive the transition from UMA to UMA 2.0 and inform various healthcare regulatory priorities. We then jumped on SSI immediately and added it to the UMA 2 AS we call Trustee. Now we are trying to align SSI and GNAP in order to enable human-centered protocols and zero-trust architecture. 
     
    - What are the implications in terms of user experience?
    Right now, the human-centered user experience assumes a secure element and web browser as user agents on a mobile device. Neither of these is readily accessible as a server nor are they designed to accept code plug-ins that represent the policies of an AS. One major exception is people adding advertising and surveillance blockers like EFF Privacy Badger to their browser. 

    The user experience implications of having SSI data model standards and GNAP protocol standards is that today's password managers (I have 250 RS relationships in mine) will evolve to also control an AS agent. Just like I might register a W3C DID with an RS instead of an email address, my policy manager might display to me the token policies that will be applied by my AS to the personal data I can control at that RS. 

    In some cases, my AS will allow me to modify those policies just like the obnoxious cookie policy settings do today. The BIG difference with GNAP is that I choose my AS separately from the RS so the dark patterns associated with today's cookie policies experience are no longer possible. GNAP means the RS exposes an API rather than a UI.

    I've gone on far too long to address the issue of the AS as an identity provider. It's fair to think of it that way. As it turns out, in the SSI Secure Data Storage WG, we are debating the difference between an Encrypted Data Vault and an Identity Hub. As far as I'm concerned, the Identity Hub is mostly a GNAP AS. Join us on Thursdays at 4 PM ET https://lists.identity.foundation/g/sds-wg/wiki/Home 

    Adrian



    On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


    Am 19.02.2021 um 23:50 schrieb Adrian Gropper <agropper@healthurl.com>:

    
    I agree with the first two of Justin's responses but not the last one.

    It's confusing to think that there are more RS than AS.

    the OAuth deployments I‘m aware of typically have much more RSs than ASs. Why? Because AS and a set of RSs belong to the same security domain (e.g. a certain business) and it’s the AS’s responsibility to ensure secure and convenient access to the APIs provided by this RSs. For example: there is a AS controlling access to a cloud, streaming, and messaging services of the same business. In case of open banking, the bank‘s AS is (on behalf of the user) authorizing access to APIs for account information as well as payment initiation and potentially other services. 

    Technically, the respective AS and RSs set up a trust relationship and agreed on ways to share authorization and user data in order enable secure API access.

    I read your ideas regarding self-sovereign ASs with great interest and got some observations/questions:
    - A personal AS could certainly control access to a person‘s resources. I assume the person‘s RSs would only accept access tokens signed by the RO. Am I right?
    - Do you envision this AS to be able to control access to any kind of RS? How is the AS supposed to know what authorization data this RS needs in order to perform access control decisions? What data will be exchanged?
    - How would this person delegate access to her resources to someone else?
    - Are you aware of deployments implementing this philosophy?
    - What are the implications in terms of user experience?

    In my experience coupling between AS and RS is very tight. I have a hard time to see how self-sovereign ASs would work. It feels like such an AS in the end is an identity provider of some sort, which brings me to what Justin proposed. I would assume using SSI credentials to authenticate towards ASs is feasible and might have value but I‘m skeptical about the AS part.

    best regards,
    Torsten.

    From a human-centered (and hopefully IETF) perspective, each person might control or specify a different AS for each of their personas or for each child or incompetent delegate of them as guardian. We're familiar with separate gmail addresses for each persona.

    ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial bitcoin wallet), or brokers (as in data brokers and surveillance capitalism). Any RS that is willing to have a recurring relationship with a persona could accept a GNAP AS endpoint instead of an email address. This is easiest using HTTP, but GNAP need not exclude other RS / AS APIs and transports. Designing around the uncensored specification of one's AS as a human right would greatly simplify many aspects of GNAP adoption.

    That said, GNAP should not ignore the RS business or jurisdictional reasons to limit the authority of the AS. UMA 2.0 spent years dancing around this issue with ideas like "cascading" AS and various centralized or federated AS concepts. My conclusion is that any RS can always do whatever it wants and there's not much the authorization protocol can help with other than specifying a notification endpoint so that an RS can warn (and seek confirmation) or log various exceptions. This turns out to be, after a year of testimony, the regulation that applies to HIPAA RS APIs in the US. For this reason GNAP might include a notification protocol in the AS specification, or not.

    I propose that embracing a self-sovereign agent is key to harmonizing the SSI and GNAP standards.

    Adrian

    On Fri, Feb 19, 2021 at 2:30 PM Justin Richer <jricher@mit.edu> wrote:
    Tobias, thanks for the great observations. Some reactions inline below.

    On Feb 18, 2021, at 7:59 PM, Tobias Looker <tobias.looker@mattr.global> wrote:

    Justin,

    I think this is a great and timely conversation to be having given the current interest around SSI and efforts like SIOP, I have been doing quite a bit of work in this space as of recent, so thought I'd add a few of the observations that I've made.

    In my opinion SIOP was really a bucket for solving quite a few different problems, not just one. In particular I think its intent was to solve 3 major ones:

    1. Enabling portable identities
    2. Solving the NASCAR problem
    3. Exploring different deployment models for the provider

    To drill down briefly on these, note much of my terminology is OpenID based due to SIOPs origin 

    Enabling portable identities - In general today in the case of OpenID, the end-users identity as understood by a relying party is scoped within the domain of the provider. Which means if that provider goes out of business or for whatever reason decides to no longer offer the same identity services to the End-User, their identity is essentially gone. Whilst there has been some interesting related work from groups like MODRNA on solutions to combat this like 'Account Porting', they often assume the old provider remains online and willing to facilitate in the account porting process so that the End-User can migrate to a new provider. SIOP actually elected to do something different here by using cryptography, instead of the End-User identifier being something like a GUID asserted within the domain of the provider, SIOP defined this instead as a public key fingerprint associated to a private key that's assumed to be under the control of the user. In doing so the identity itself becomes portable between providers by transferring the associated private key. Now this approach does have drawbacks and arguably encourages what many would refer to as bad cryptographic practise by not allowing any way to do key rotation, however the idea was there. 

    How GNAP can solve for this? By having flexibility around how the resource owner / End-User is referred to by the Authorization server (e.g allow the identifier to be something like a public key or a resolvable identifier to public keys such as a DID)

    I personally think that GNAP should be a flexible :carrier: of identifiers and other bits of identity information. This is the main reason we went with the Subject Identifiers draft from SECEVENT: it’s set up to talk about a variety of different kinds of identifiers, all of them asserted in the context of the AS. If there’s a definition for a DID URL or a JWK in the sub_ids object structure, GNAP would be able to just use it directly alongside every other format. I haven’t seen those proposed yet, but it would be easy to do and, in my mind, would be a better solution than the portable identifiers proposal that was recently brought up in the FAPI working group in OIDF. (A side note, but the main problem I have here is that it’s pasting semantics and formats onto a field where none existed before, and that’s rife for problems. Better to have a structure that takes that into account from the start, in my view.)


    Solving the NASCAR problem - One of those enduring problems in identity systems, which I think is really about the three way negotiation going on between the RP, the End-User and the Provider. SIOP's solution pushed for most of the power in this decision making process to lie with the End-User, letting them decide who they want as their provider rather than RP's providing an enumeration of who they support via provider icons on their login page and End-Users having to select from those options. It accomplished this via using a custom URL scheme of `openid://` where the End-User would register their chosen provider as a protocol handler for the `openid://` scheme. However, again as a solution it's not without it's challenges, notably; only a single registration at a time can be supported, the actual identity of the provider remains blind to the RP until after the request is sent and it requires registration or some form of default handling (e.g when there is no provider registered).

    How GNAP can solve for this? I actually don't think this is core to GNAP, there may be some considerations around discovery that are worth paying attention to but not much in the core protocol design.


    SIOP doesn’t really solve the NASCAR issue since SIOP, by design, becomes yet one more login option among many. I think GNAP can help this by enabling user-directed provider discovery to kick off the process, but I agree that the core protocol doesn’t really have much to say here, and shouldn’t.

    Exploring different deployment models for the provider - This is the most frequently talked about aspect of SIOP and perhaps the most interesting to GNAP. I like to think about the scope of this issue as designing to allow for either a partially or fully distributed/decentralized provider, rather than a centralized one (e.g an HTTP based AuthZ server). As you noted this does come with its challenges many of which are technical in nature, i.e how to appropriately address a decentralized provider and what protocols are used to communicate with the provider.

    How GNAP can solve for this? I think that's what much of the discussion on this thread will be about and whether there is a hybrid model where some responsibility is still centrally administered like token issuance, while allowing other aspects to occur in a more distributed manner. Ideally though I'd like to see consideration for a completely distributed model too.

    I agree that this seems to be the most interesting place for overlap. I don’t actually think the “hybrid” approach centralizes things. Instead, you can think of the RS as having an associated AS, and that AS accepting user consent and claims at runtime from a variety of sources (wallets, VCs, etc.). In this way, we aren’t talking about a single AS in the world handling all of these requests, we’re talking about a distributed network of AS’s associated with an even more widely distributed set of RS’s. SSI and its associated technologies would help these “local” AS’s issue access tokens without the RO needing to have an account, or even necessarily directly interacting with the AS. There’s currently a technology gap there, but my thoughts are that this is where the changes to the interaction modes section can really come to play. 

    I think the notion of a non-HTTP AS is interesting, but I’m not sure if that’s something GNAP ought to be solving for. I think that there’s a deep value in building on top of HTTP for the core protocol, and not abstracting away concepts from it. Otherwise, you end up re-inventing layers, and you get something like SOAP all over again. :)

     — Justin


    Thanks,
    Mattr website  
    Tobias Looker
    Mattr
    +64 (0) 27 378 0461
    tobias.looker@mattr.global
    Mattr website Mattr on LinkedIn Mattr on Twitter Mattr on Github

    This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


    On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justin,

    I agree that defining AS role primarily as a token issuer is a fruitful idea. Solving this problem well would also respond to the challenges discussed previously on the list. 

    Cheers
    Fabien 


    Le mer. 17 févr. 2021 à 23:27, Justin Richer <jricher@mit.edu> a écrit :
    The last interim call had a lot of discussion on SSI technologies such as digital wallets, and how those fit with GNAP. I think it’s worth continuing that conversation here on the list. There are a few issues in the tracker that give some background, too:


    There’s been a lot of interesting work recently in the OpenID Foundation around using the Self-issued OP (SIOP) functionality to bootstrap an SSI style login. This makes extensive use of the implicit flow and front channel messaging, but minimization of the front channel for message passing is a key design tenet of GNAP (so much so that it’s included in our charter). Instead, GNAP has been built around an idea that everything starts the same way: with an HTTP request to the AS. 

    The idea of an on-device AS has been brought up a lot, and we need to consider if and how we want to deal with these kinds of use cases. The most obvious way to address these would be to do some kind of clever off-HTTP hack like SIOP, but keep in mind that even SIOP generally starts off with an HTTP-based discovery call by the RP to make things work.

    My personal stance is that to do this, we need to re-evaluate our assumptions about exactly what an AS does and what it needs to do those things. In OAuth 2, it’s assumed that the AS is the device that’s authenticating the user, collecting consent, managing the client’s registration, and creating an access token based on whatever set of rights that are associated with all of those things. In UMA, this is turned around a bit by letting the RO present a bunch of nebulous “claims” interactively, but still at the AS. 

    With both of these, a key aspect remains: the AS needs to gather necessary information, and issue the access token (or identifiers/assertions). Because of how the protocol works, the client software now has a better opportunity to present information to the AS, either directly in the request or by introducing the AS to another software component during the “interaction” phase. So, what if we think of the AS primarily as a “token issuer”? 

    For example, if the client can present a verifiable credential (VC) that represents the end user, the AS can validate that VC and make an access token on behalf of that user, without having the user log in or interact with the AS at all. This VC can contain whatever access rights the token needs to represent, and the AS can translate that into an artifact that the downstream RS’s can interpret, without having to see the original VC or the user at all. The AS is still HTTP based, but all the essential security and rights elements are provided by the wallet. In this way, we can expand on the privacy-preserving aspects of OAuth and bridge the worlds of SSI and web APIs without violating the basic nature of either.

    Coming from the OAuth world, it feels weird to issue tokens like this, but there’s precedent for this kind of thing. Today, a there are a number of service-based OAuth AS's that are told what claims need to get put into the access token by some trusted component. All of this happens outside the OAuth protocol. In GNAP, I think it makes sense to account for this kind of thing in how we define the protocol. That isn’t to say all of these pieces need to be defined in the core, but the base protocol ought to be able to handle being extended in this direction as needed.

    I’m really interested to hear other people’s thoughts on how this could come together.

     — Justin
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3avsUGQ48fo1OUQV0vyyKd



    --------------C34E848C58BACC2A73162655-- From nobody Wed Feb 24 09:09:14 2021 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 584DF3A09C3 for ; Wed, 24 Feb 2021 09:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=adorsys.de 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 QI_GybOQI_9E for ; Wed, 24 Feb 2021 09:09:06 -0800 (PST) Received: from DEU01-FR2-obe.outbound.protection.outlook.com (mail-fr2deu01on20718.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e24::718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF353A0AAF for ; Wed, 24 Feb 2021 09:08:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OfLIEk7yOmEr+oDZW3UMNudxqVDeLFwg3vvpNA0WY02aU3OYaI+YtYP+uNcBlvgyogMVaFULmMPq5iXrYOnJ3ZLDa2hNvs97fl1UyEzYV+AImEyo5+n7mI+4WRbXgjWtX2WMPv2O4Q6JHYN82/E6h0zMBrFeH0lqtDLeAQ5p05nfkpIy+wr1R5SBMSjwbNVDNG+pGh8VTMiRl9JdGA6u7OQ46C4R68TndRrtq0+ADX9u2OTMKZuF8nujknv99dDmk8P3npLf3VqrC/0swdUDjoulcCtDcDIp7PgtOsj1kw1NGZQ5K5q2nfHJtkaW5KuFmXPKfh5ihLAkwiy9zpPmEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oAR1KNbb21LV6MbZA0Lsa68wqF9iI4B6d22t9b2kLJU=; b=hUGePtiW75lzKSLuLPFSBNiiiOBiiceW4g8qi/XYtj0hBrtleLo0oMR9MRXvYzOs87rBhO6deYDelt/UsV8ZoFsq43JwJ0xHz4BHtiPjsWqnY/Io65HjtO8U/UsdeRkU6r+3J4LVfQMFSOMaHx75uZcb1uCDzIVtUMvJdIJw+yomV3ot9TmydVl2Ezlf8/ROAXgnZr+cozPFSyHLSTJRXHJ0WsBIKgHCnccbJBYPlpxnEYluA8dJElZK3id3KudlJeDtCIQ1esjcDbxycuiUb10FHsuA9o4/cwWSxbS3Cn92Q3JH184h+cbZQnj5e0ASOVI2KDMMv7AB+ocvTTctPQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=adorsys.de; dmarc=pass action=none header.from=adorsys.de; dkim=pass header.d=adorsys.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oAR1KNbb21LV6MbZA0Lsa68wqF9iI4B6d22t9b2kLJU=; b=vLi5xFvo6BOXtGAmXXtMV4lzRNZtHbb2RSi+951dey6XZCNNVbDWE0pgS25hkN+IxjgJZ5D2XeXp3fz65OAmnn5IzEOz/Q/47/QvNlpxx/jgYZMf0xRXD7nx9FpIn67nWbQ6yA2dEq3eXAzGTJJMDdE7pXQwqHkqDmeq/1/jiBtbiyv7+6xOMUb+Pwb5k7XneK+MzgwJBVDPrUkBXdFyVsfGJO5s8XVneMlJ+QUZoQayQzo4msozdRyv5liOsxVHmH+jxfohgo5WxxTnM1yNLcUmxG20qFFA4hlCHvG/Wkv6yKgPmKaDSO5po9qtzyuvp7UsKGqwd4pme7ICd0N7Aw== Received: from FR2P281MB0138.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:10::8) by FRYP281MB0224.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:5::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.9; Wed, 24 Feb 2021 17:08:49 +0000 Received: from FR2P281MB0138.DEUP281.PROD.OUTLOOK.COM ([fe80::bc2b:fddf:d610:ee71]) by FR2P281MB0138.DEUP281.PROD.OUTLOOK.COM ([fe80::bc2b:fddf:d610:ee71%3]) with mapi id 15.20.3912.009; Wed, 24 Feb 2021 17:08:49 +0000 From: Francis Pouatcha To: Denis , Justin Richer , txauth gnap Thread-Topic: [GNAP] Integrating a GNAP AS with wallets and SSI Thread-Index: AQHXBXwe7b9/rWIGR0yOF6btTivnUKpdknMAgAEXjYCAATZHgIAAN+AAgAJGUgCAAFWagIAB1VCAgAEwxwCAAcSN7w== Date: Wed, 24 Feb 2021 17:08:49 +0000 Message-ID: References: <4EAA60A4-4800-400F-A70A-F7B7F1A6CB0A@mit.edu>, <73cd4e8b-c843-ab87-c640-eea763b6002a@free.fr> In-Reply-To: <73cd4e8b-c843-ab87-c640-eea763b6002a@free.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: free.fr; dkim=none (message not signed) header.d=none;free.fr; dmarc=none action=none header.from=adorsys.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2603:9000:780a:f3b8:9035:d2d:198b:699a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b39e7119-5af7-49a3-77a5-08d8d8e6da84 x-ms-traffictypediagnostic: FRYP281MB0224: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: a7dAMfVarsDyysoCo6arEGjURbJycR2KOOkm2P5B417wBNYPNLFoQE79w2cD1pt5DEKAiHbhqsq1j6HjwPmR0LLAKyBq2z5AJ6Hh99D0ogcS1+xlsrwfXLgtE59oGe2eKYFTidQbCt/f5bDJH6HlZAeA5xZAkqhxPBMxBENzt8H71NBZn0e1wpnSIrrGGDgex/M+D5hESdZSNYz1VN0Ggs/bkDPcqQ8S3pprZ1J5Y7vMms7LIjTgZdhUEIVCrhAi97jP96jiC4ICWIs9F4BQNkodUDnBupAZnnEGB2e7WH5ueJPU4/i1q92blh6p8xpNPNeMe01kvuVueYacQo9Ssa7tbI18SovU4ET1F+RSHvP/GmPEkcGSrwUK8W+UnElNYPbvY4Ucj7Xi0WX9ihMTnBFJEctI0UdtPwkvS52KsbV0Hv+h/0+JhMLDmNZLm3JrBQg2Hjf4k5KcFdbaXdRQgAQdokoE188PR6VWprnNqYkaNfcCESkiMW307DDd6QYxBUESwL3sUYw/F7sLcUi0Va+M91ELtWaInPVPHZvgPExEgPt/Cg+0iWo5WgyL9WBKrtsQRqb0D/FBjYJiBqJ7Km27++MfrTCu719jmB12pde5Cz4JZ5fBuRlUZ/7dOKWl/0fT0vk+qrjbI3WCR3QpSQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0138.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(366004)(39830400003)(136003)(346002)(76116006)(91956017)(71200400001)(9686003)(52536014)(66476007)(66556008)(64756008)(66446008)(186003)(110136005)(86362001)(66946007)(8676002)(966005)(8936002)(6506007)(53546011)(55016002)(7696005)(478600001)(33656002)(5660300002)(30864003)(83380400001)(66574015)(19627405001)(2906002)(166002)(316002)(18074004)(15866825006)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?ckUva0xoZStmNjhpNFRKZ1UwRzJ4QnUrVTJvQkJUMHQ1TzZCVzdoenpacjg1?= =?utf-8?B?NGtvOEUyTHp6c1pya0lQRUwrU3B3WGVCemM1a3lzOUxCdEJzOERveWt2MEY1?= =?utf-8?B?eUdzU3NaZ1dsSXhQZFljRGdHNmJ5QytpVnJzbE14MytGcm5XQUlXejdmOWhG?= =?utf-8?B?WEthVG9ZUW42aUdqOHBUU2p6Zk5jZUNJcDM3MXc2ZzcwT2ViTFgyT3FvNlFv?= =?utf-8?B?dW1xSnVSM1VCYXpUTEQ5YUE2N0JYSUd1WktwcmR1TUxQblVjbXZ3NkwrQ050?= =?utf-8?B?Wk9pRUxuNFpwdHJRZ3QvM2FLNUxOUHZDYTZ1U3hxNm9vdXZuWnBCN2ZLdmhk?= =?utf-8?B?UktJTVBNWms3VzQ2cEx6Vit4Q0psN1lYM08wWHVOVzQwZERRcmpYL21KT3hR?= =?utf-8?B?UXBXWWdJb1hoN1U1QmlNalNMQ1g1dEtkT0ZvWWFlejRQZ3llWk5LMTNTTDBX?= =?utf-8?B?TGV1a3RsSzJacVFIV2JDcjdXUnZmSHRaa2JyQnJnV1VnZXRoYlRsRmNac1Bv?= =?utf-8?B?bHExVWhLLzQ1VGpSeE1HU3JOQzB2YytsY0xxVHlsS0NtVEJnazBVaXVMODNr?= =?utf-8?B?N0dPSFBEY1ZtU2hLcGgzWXJFcm9zUW9wUGxSZlhORzNBcWcybVh4Mk5mNTdk?= =?utf-8?B?MUFjNzlJQW0xbzlpZytsY0FGcVcrU3JkVmJhWWZFQWYza05ycTkrb3lEWTY1?= =?utf-8?B?NGZPWWVVVWU2UW12SzJCUk5GL1ppblZWSnQ2TVdmd0sxUExGYk0rWUh4bUxK?= =?utf-8?B?WUg5NHJxQkFzS1hDbCt6UFJkYWVzckt6MU4vL2tmVzQrNyt0NkE4MTJGY2xC?= =?utf-8?B?TmFnMjF6ZTB1R2FyQldQTFZGMmVIMUdERjcyK0Z2RHptcDRDYW9LQ3M1Wjhw?= =?utf-8?B?ZFQrRllwSldwS1lDYkYvVjdpdXorcW9oZ0wvSkVxSldPR2FxMWkrVWJHS2tU?= =?utf-8?B?TUtaT0RRL0VjNk9KWkgwM2srbUpKMVlWSmo0aFZYRGdOVzNTQ1k4RmFpc3pT?= =?utf-8?B?akNUZGtUczN6U1ZjLzdiQ21IWTFnWXlkRzdXZCtTMTRnaXZneWlKQ0p3ZVFL?= =?utf-8?B?V2grYUtVeGd2dXVKRUxkSU5oVkJlODNDWm45ZEE2NUNEUDlYOGwvQy9KRDR2?= =?utf-8?B?MWgzOEdzQjRMcXJTMkJyTmV0R2tHVDNFWFFsL3R0STB2MG5EQXpRQVNEbi9Y?= =?utf-8?B?NEt6WmNyUkR6R0Z3TTN3TzVpaWlLV05FckhLMEtBREpSS3Era3dIYko0M2Ey?= =?utf-8?B?YU1sRkpqaTdTK1pVT2o0Z2FCZWx0VkliQ3BDSFBxNVFVUHpKQzlYZzUzTXZz?= =?utf-8?B?NURMMVFCeHBVWDZveEZuU0xEdW5wQ096alBzM0FzczErTHJpcTJ1YUF5RzNk?= =?utf-8?B?UU9hbk9BUE92SHFIZTlCRG9CUmdFZjRIWFBNOUZWZXNLSGRIQkorTTU3UUFC?= =?utf-8?B?ZCtNSEV4dTk5aDRGRnN3blNJL2xmbWZFa0NBeThZSTZJMC8yNENVbGJtTG9n?= =?utf-8?B?VGY2TlRGNG0yZnJUYTdGNnFVc3FheVlQNW5IY1VuUmpZQk1QUElBNVhpMWF5?= =?utf-8?B?YVp3VFJNaWRHTEszQVhibXVHbHpHc3V2ak5BclBtVjFra1dtMlYzQlFFQ2Nk?= =?utf-8?Q?YadZ5sJhFAF+yl0bVsyWjfOMZjDYbFP/OS56Milqeq9A=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FR2P281MB013815C2EA1CC7FEBAB88FD08D9F9FR2P281MB0138DEUP_" MIME-Version: 1.0 X-OriginatorOrg: adorsys.de X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0138.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: b39e7119-5af7-49a3-77a5-08d8d8e6da84 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2021 17:08:49.2161 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5e2c5484-e522-479d-91ca-515d6e0ce228 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wRHc9tsm7TMoOI8T+euebuIAp1PJphI2AZmut7545KZo3khlhCs9ypKtPpaxqNgjv6pGlXKuBOvvk4EqEfAtXMBkm0ImjWcmcXSy/w17dmg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRYP281MB0224 Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 17:09:12 -0000 --_000_FR2P281MB013815C2EA1CC7FEBAB88FD08D9F9FR2P281MB0138DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW50ZWdyYXRpbmcgR05BUCBhbmQgU1NJIHJlcXVpcmVzIGEgbG90IG9mIGZ1bmRhbWVudGFsczoN Cg0KDQogICogICBBUyBoYWQgdGhlaXIgZXNzZW5jZSBpbiB0aGUgZmFjdCB0aGF0IGh1bWFuIGhl bGQgZGV2aWNlcyB3ZXJlIG5vdCBhYmxlIHRvIHByb2R1Y2UgYXV0aG9yaXphdGlvbiBzaGFyYWJs ZSB0byBjbGllbnQgYW5kIFJTDQogICogICBJZiB0aGUgaHVtYW4gaGVsZCBkZXZpY2UgY2FuIGRv IHRoZSB3b3JrLCBpdCBpcyBuYXR1cmFsIHRoZSBtb21lbnR1bSB3aWxsIHNoaWZ0IGluIHRoYXQg ZGlyZWN0aW9uLiBUaGlzIGlzIHdoYXQgaXMgaGFwcGVuaW5nIHdpdGggU1NJLg0KICAqICAgU2hh cmluZyBhbGwgdmlld3Mgb2YgQWRyaWFuIG1lbnRpb24gaW4gdGhpcyB0aHJlYWQobm8gbmVlZCB0 byByZXBlYXQpLg0KICAqICAgQnV0IHJlcGVhdGluZyB0aGUga2V5d29yZDogWlRBLiBLZWVwaW5n IGN1c3RvZGlhbiwgc2VydmVyIGNlbnRlcmVkIGFyY2hpdGVjdHVyZXMgdW5kZXIgY29udHJvbCBp cyBnZXR0aW5nIHRvdWdoZXIgYXMgdGltZSBnb2VzIGJ5Lg0KDQpJbiBHTkFQIGluaXRpYWwgZGlz Y3Vzc2lvbiwgd2Ugd2Fsa2VkIHRocm91Z2ggYSBsb3Qgb2YgYWJzdHJhY3QgZGlhZ3JhbSwgdGhh dCBjb3VsZCBoYXZlIGFsbG93ZWQgcHJvZHVjdGlvbiBvZiBhdXRob3JpemF0aW9uIGFuZCBhdXRo ZW50aWNhdGlvbiBtYXRlcmlhbCAodG9rZW4pIGJ5IGh1bWFuIGhlbGQgZGV2aWNlcy4gVGhlIGlu dGVudGlvbiB3YXMgaW5zcGlyZWQgZnJvbSBTU0kgZGlzY3Vzc2lvbnMuDQoNCklGDQogIEp1c3Rp biBpcyBhc2tpbmcgdG8gcmVjb25zaWRlciBhbiBpbnRlZ3JhdGlvbiBvZiBTU0ksDQoNClRIRU4N CndlIG5lZWQgdG8gcmV2aWV3IHRoZSBhYnN0cmFjdCBwcm90b2NvbCBmbG93czoNCg0KICAqICAg cm9sZXMNCiAgKiAgIGVudGl0aWVzDQogICogICByZWxhdGlvbnNoaXBzDQoNCldlIHdpbGwgaGF2 ZSB0byBzdGFydCBieSB0YWtpbmcgdGhlIGh0dHAgcHJvdG9jb2wgY29uc3RyYWludCBvdXQgb2Yg dGhlIGNoYXJ0ZXIuDQoNCkJUVw0KDQogICogICBJIGFncmVlIHdpdGggSnVzdGluOiAiVGhlIFJT IGRlY2lkZXMgb24gaG93IHRvIGNvbnN1bWUgYSBwcmVzZW50ZWQgdG9rZW4uIg0KICAqICAgSSBh Z3JlZSB3aXRoIERlbmlzOiAiQVMgcGxheXMgbm8gcm9sZSBhbmQgc2hhbGwgaGF2ZSBubyBpbmZs dWVuY2Ugb24gdGhlIFJTIGRlY2lzaW9uIG9uIGhvdyB0byBjb25zdW1lIGEgdG9rZW4uIg0KDQpU SEVODQpXZSBtdXN0IHN0YXJ0IGJ5IHNoYXJwaW5nIHRoZSBtZWFuaW5nIG9mIGFuIEFTIChpbiB0 aGUgY29udGV4dCBvZiBHTkFQKS4gRGlzY3Vzc2lvbiBtaWdodCBsZWFkIHRvIGEgcmV0aXJlbWVu dCBvZiB0aGlzIHRlcm0uIEFzIG1vcnRhbHMgbWlnaHQgaGF2ZSBhIGhhcmQgdGltZSBjb25zaWRl cmluZyBhIHVzZXIgaGVsZCBkZXZpY2UgYSBzZXJ2ZXIuDQoNCkVORCBJRg0KDQoNCk5ldmVydGhl bGVzcywgdGhlIHRyYW5zaXRpb24gZnJvbSAoaHR0cCktQVMgYmFzZWQgdG9rZW4gcHJvZHVjdGlv biB0byB1c2VyIGRldmljZS1iYXNlZCB0b2tlbiBwcm9kdWN0aW9uIHdpbGwgbmVlZCBzb21lIDEw KyB5ZWFycyB0byBjb21wbGV0ZS4gU3RpbGwgYSBsb3Qgb2YgY2hhbGxlbmdlcyBhcm91bmQgaG93 IHRvIHByb3RlY3Qga2V5cyBoZWxkIG9uIHVzZXIgZGV2aWNlcyBhZ2FpbnN0IGRhbWFnZSwgbG9z cyBvZiBkZXZpY2UsIG1hbHdhcmUsIHJhbnNvbXdhcmUsIHNvY2lhbCBlbmdpbmVlcmVkIGF0dGFj ay4NCg0KQ2FuIEdOQVAgYmUgdGhlIG1haW4gdmVoaWNsZSBmb3IgdGhpcyB0cmFuc2l0aW9uPyBN YXliZS4gRGVzcGl0ZSB0aGUgKHRvbykgc3Ryb25nIHJlbGlhbmNlIG9uIHRoZSBPQXV0aCBsZWdh Y3kgKGV2ZW4gaWYgR05BUCBkb2VzIG5vdCBwcm9taXNlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkg dG8gT0F1dGgpLCBhbiBlbWJlZGRlZCBpbnRlcmFjdGlvbiB0aGF0IGFsbG93cyB0aGUgY2xpZW50 IHRvIGNhcnJ5IHRoZSB1c2VyIGRldmljZSBwcm9kdWNlZCB0b2tlbiB0byB0aGUgcmVzb3VyY2Ug c2VydmVyIG1pZ2h0IHBhdmUgd2F5IGZvciB0aGlzIHRyYW5zaXRpb24uIEkgY2FtcGFpZ25lZCBm b3IgY29uc2lkZXJhdGlvbiBvZiBhbiBlbWJlZGRlZCBpbnRlcmFjdGlvbiBpbiB0aGUgaW5pdGlh bCBjb252ZXJzYXRpb24uIEkgYW0gbm90IHN1cmUgdGhpcyB3YXMgdGFrZW4gaW50byBhY2NvdW50 LiBTdGlsbCBtdXN0IGZpbmQgdGltZSB0byByZXZpZXcgdGhlIGN1cnJlbnQgZHJhZnQuDQoNCg0K L0ZyYW5jaXMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogVFhB dXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIERlbmlzIDxkZW5pcy5p ZXRmQGZyZWUuZnI+DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyMywgMjAyMSAxMjo1MSBQTQ0K VG86IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT47IHR4YXV0aCBnbmFwIDx0eGF1dGhA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0dOQVBdIEludGVncmF0aW5nIGEgR05BUCBBUyB3aXRo IHdhbGxldHMgYW5kIFNTSQ0KDQpIaSAgSnVzdGluLA0KDQpTZWUgbXkgY29tbWVudHMgYmV0d2Vl biB0aGUgbGluZXMuDQpBbiBpbXBvcnRhbnQgYXNwZWN0IGluIHRoZSBkaXNjdXNzaW9uIGhlcmUs IHRoYXQgSSBhZ3JlZSB3aXRoLCBpcyB0aGF0IHRoZSBSUyBuZWVkcyB0byBiZSBhYmxlIHRvIGRl Y2lkZSB3aGljaCBBUyBpdCB0YWxrcyB0by4NCg0KIFdoaWxlIEkgd291bGQgYWdyZWUgd2l0aCBz dWNoIGEgc2VudGVuY2UgaW4gdGhlIE9BdXRoIFdHLCBJIGRvbid0IGJlbGlldmUgdGhhdCB0aGlz IHNlbnRlbmNlIGlzIGFwcGxpY2FibGUgaW4gZ2VuZXJhbCBpbiB0aGUgY29udGV4dCBvZiBHTkFQ Lg0KQSBSUyBkb2VzIG5vdCBuZWVkIHRvICJ0YWxrIHRvIiBhbnkgQVMuIEEgUlMgZGVjaWRlcyB3 aGljaCBBUyhzKSBpdCB0cnVzdHMgdG8gaXNzdWUgYWNjZXNzIHRva2VucyB0aGF0IGNvbnRhaW5z IHNvbWUgc2V0IG9mIHByaXZpbGVnZXMuDQoNCkJ1dCBpbmhlcmVudCBpbiB0aGF0IGlzIHRoYXQg aXTigJlzIG5vdCB0aGUgdXNlcuKAmXMgZGVjaXNpb24sIG9yIHRoZSBBU+KAmXMgZGVjaXNpb24s IGl04oCZcyB0aGUgUlPigJlzIGRlY2lzaW9uIHdobyBpdCB3aWxsIHRydXN0IHRvIGdldCB0b2tl bnMgZnJvbS4NCg0KQSBSUyBkb2VzIG5vdCBuZWNlc3NhcmlseSBuZWVkIHRvIHRydXN0IGFsbCB0 aGUgYWNjZXNzIHRva2VucyBpc3N1ZWQgYnkgYSBnaXZlbiBBUywgYnV0IG9ubHkgYWNjZXNzIHRv a2VucyBmcm9tIGEgZ2l2ZW4gQVMgdGhhdCBjb250YWluDQphIGdpdmVuIHNldCBvZiBwcml2aWxl Z2VzLg0KDQpBbmQgbm8gbWF0dGVyIHdoYXQgb3VyIHBoaWxvc29waHksIGF0IHRoZSBlbmQgb2Yg dGhlIGRheSB0aGUgUlMgd2lsbCBhbHdheXMgaGF2ZSB0aGUgY2hvaWNlIG9mIHdoZXRoZXIgdG8g dHJ1c3QgYW4gaW5ib3VuZCByZXF1ZXN0Lg0KDQpOb3QgZXhhY3RseTogdGhlIFJTIHdpbGwgYXBw bHkgdGhlIHJ1bGVzIGdpdmVuIGJ5IHRoZSBSTy4NCg0KV2hpY2ggaXMgd2h5LCB0byBtZSwgdGhp cyByZWFsbHkgYnJpbmdzIHVzIHRvIHRoZSBxdWVzdGlvbiBvZiB3aGF0IGFuIEFTIHByb3ZpZGVz LiBUaGUgQVMgZ2l2ZXMgdGhlIFJTIGEgdG9rZW4gdGhhdCB0aGUgUlMgZGVjaWRlcyB0byB0cnVz dCwNCmFuZCB0aGF0IHRoZSBSUyBjYW4gdW5kZXJzdGFuZCAoZWl0aGVyIGRpcmVjdGx5IHdpdGgg c29tZXRoaW5nIGxpa2UgSldUIG9yIGluZGlyZWN0bHkgd2l0aCBzb21ldGhpbmcgbGlrZSBpbnRy b3NwZWN0aW9uKS4NCkJ1dCB0aGUgQVMgYWxzbyBuZWVkcyB0byBkZWNpZGUgd2hhdCB0byBwdXQg SU5UTyB0aGF0IHRva2VuLiBBcyBhIGNvbnNlcXVlbmNlLCB0aGUgQVMgY2FuIGdldCB0aGF0IGlu Zm9ybWF0aW9uIGZyb20gYW55IG51bWJlciBvZiBwbGFjZXMuDQpUaGUgaW5mb3JtYXRpb24gY291 bGQgYmUgcHJvdmlkZWQgaW4gYSB0cnVzdGVkIHdheSBieSB0aGUgZW5kIHVzZXIgdG8gdGhlIEFT IOKAlCBidXQgdGhpcyBkb2VzIE5PVCBuZWNlc3NhcmlseSBtZWFuIHRoYXQgdGhlIEFTIGJlbG9u Z3MNCnRvIHRoZSB1c2VyIG9yIGlzIHVuZGVyIHRoZWlyIGNvbnRyb2wuDQoNCkJhc2ljYWxseSwg SSB0aGluayB3ZeKAmXJlIHRyeWluZyB0byBoYXJkIHRvIG1hcCB0aGUgT0F1dGggZ2VuZXJhbC1j b25jZXB0IG9mIHRoZSBSTyBoYXZpbmcgYW4gYWNjb3VudCBhdCB0aGUgQVMgYW5kIGxvZ2dpbmcg aW4gdG8gaXQgYmVmb3JlIGF1dGhvcml6aW5nIHRoZSByZXF1ZXN0Lg0KSSB0aGluayB0aGF0IHRo ZSBjYWxsIGZvciDigJxldmVyeSB1c2VyIHRvIGhhdmUgdGhlaXIgb3duIEFT4oCdIGlzIHN1Y2gg YSBodWdlIG5vbi1zdGFydGVyIGluIHNvIG1hbnkgZG9tYWlucyB0aGF0IGl0IGhhbXBlcnMgdGhl IHNvbHV0aW9uIHNwYWNlIGlmIHRoYXTigJlzIHdoYXQgd2UgcHJlc3VtZS4NCkl04oCZcyB1cCB0 byB0aGUgUlMgdG8gZGVjaWRlIHdobyBpdCB0cnVzdHMsIG5vdCB0aGUgZW5kIHVzZXIgYW5kIG5v dCB0aGUgUk8uDQoNCkkgdGhpbmsgd2Ugc2hvdWxkIEFMTE9XIGl0LCBhbmQgd2UgY2FuIGJlIGNs ZWFyZXIgaW4gR05BUCB0aGF0IHRoYXTigJlzIG9uZSBwb3NzaWJsZSBtb2RlbCwgYnV0IG5vdCB0 aGUgb25seSBvbmUsIGFuZCBub3QgZXZlbiB0aGUgZ2VuZXJhbCBvbmUuDQpUaGUgQVMgbWFuYWdl cyBhbGwgb2YgdGhlIGluZm9ybWF0aW9uIGFuZCBpbnRlcmNvbm5lY3Rpb25zIG5lZWRlZCB0byBj cmVhdGUgYW4gYWNjZXNzIHRva2VuIHRoYXQgdGhlIFJTIHdpbGwgYWNjZXB0LCBhbmQgaXQgaXMg aW4gY2hhcmdlIG9mIHNpZ25hbGluZyB0byB0aGUgUlMgd2hhdCB0aGF0IHRva2Vu4oCZcyBnb29k IGZvci4NCg0KSSBkaXNhZ3JlZTogdGhlIEFTIGlzIE5PVCBpbiBjaGFyZ2Ugb2Ygc2lnbmFsaW5n IHRvIHRoZSBSUyB3aGF0IHRoYXQgdG9rZW7igJlzIGdvb2QgZm9yLiBJdCBpcyB1cCB0byB0aGUg UlMgdG8gZGVjaWRlIHdoaWNoIHByaXZpbGVnZXMgaXQgd2lsbCBhY2NlcHQNCmFtb25nIGFsbCB0 aGUgcHJpdmlsZWdlcyBpbmNsdWRlZCBpbnRvIGFuIGFjY2VzcyB0b2tlbi4NCg0KSG93ZXZlciwg aWYgdGhlIEFTIGNhbiBsZWFybiB0aHJvdWdoIHNvbWUgb3RoZXIgbWVhbnMgdGhhdCBhIHNwZWNp ZmljIGlkZW50aWZpZWQgdXNlciBoYXMgY29uc2VudGVkIGFuZCBwcm92aWRlZCBhcHByb3ByaWF0 ZSBpbmZvcm1hdGlvbiBpbiBhIHRydXN0ZWQgd2F5LA0KdGhlbiBUSEFUIGluZm9ybWF0aW9uIGNh biBiZSBiYWtlZCBpbnRvIHRoZSB0b2tlbiBieSB0aGUgQVMuIOKAlCBpbXBvcnRhbnRseSwgaW4g YSB3YXkgdGhhdCB0aGUgUlPigJlzIHRoZSBBUyBwcm90ZWN0cyBjYW4gdW5kZXJzdGFuZC4NCg0K SSBkaXNhZ3JlZTogVHJ1c3QgcmVsYXRpb25zaGlwcyBhcmUgbm90IGJpbGF0ZXJhbCBidXQgb25s eSB1bmlsYXRlcmFsLiBBbiBBUyBkb2VzIG5vdCBuZWVkIHRvIGhhdmUgYW55IHNwZWNpZmljIHBy aW9yIHJlbGF0aW9uc2hpcCB3aXRoIGEgZ2l2ZW4gUlMuDQpJdCBpcyB1cCB0byB0aGUgUlMocykg dG8gZGVjaWRlIHdoaWNoIEFTKHMpIGl0IHRydXN0KHMpIGFuZCBmb3Igd2hpY2ggcHJpdmlsZWdl cy4NCg0KVGhpcyBsYXN0IGJpdCBpcyB3aGVyZSBnZW5lcmFsIG9wYWNpdHkgb2YgdG9rZW5zIGlz IGltcG9ydGFudCBoZXJlLiBUaGVyZeKAmXMgYSBuYXR1cmFsIHNlY3VyaXR5IGJvdW5kYXJ5IHRo YXQgYXJpc2VzIGZyb20gdGhpcyBtb2RlbC4gV2hhdCBJ4oCZbSBwcm9wb3NpbmcgaGVyZSBpcyBq dXN0IHRoYXQgd2XigJlyZSBtb3JlIGV4cGxpY2l0IGFib3V0IHdoYXQgY2FuIGJlIHB1dCBJTlRP IHRoYXQgYm91bmRhcnkuIFRoYXTigJlzIHdoZXJlIEnigJltIHNlZWluZyBhIGxvdCBvZiB0aGlz IGlubm92YXRpb24gaW4gdGhlIFNTSSBzcGFjZSBmaXR0aW5nLiBZb3XigJlyZSBub3QgY29taW5n IHVwIHdpdGggc29tZSB1bml2ZXJzYWwgYWNjZXNzIHRva2VuIHRoYXQgdGhlIFJTIHdpbGwgYWNj ZXB0LCBidXQgeW914oCZcmUgYWJsZSB0byBwcm92aWRlIHVuaXZlcnNhbCBjbGFpbXMgYW5kIGFy dGlmYWN0cyB0aGF0IGFuIEFTIGNhbiBwcm9jZXNzIGFuZCB0cmFuc2xhdGUgaW50byBhIHRva2Vu IHRoZSBSUyB3aWxsIGFjY2VwdCBhbmQgZG8gdGhlIHJpZ2h0IHRoaW5nIHdpdGguDQoNCllvdXIg YXJndW1lbnRhdGlvbiBhYm91dCB0b2tlbiBvcGFjaXR5IGlzIG1ha2luZyB0aGUgYXNzdW1wdGlv biB0aGF0IHRoZSBBUyBhbmQgdGhlIFJTIG5lZWQgdG8gaGF2ZSBhIHByaW9yIHJlbGF0aW9uc2hp cCBiZWZvcmUgYW55IGFjY2VzcyBjYW4gdGFrZSBwbGFjZS4NCldoaWxlIHRoaXMgd2FzIHZhbGlk IHdpdGggT0F1dGgsIHRoaXMgaXMgbm8gbW9yZSB2YWxpZCBpbiB0aGUgY29udGV4dCBvZiBHTkFQ LiAgVGhlIGNsaWVudCBzaG91bGQgYmUgYWJsZSB0byBpbmZvcm0gdGhlIEFTIGFib3V0IHRoZSBh Y2Nlc3MgdG9rZW4gZm9ybWF0KHMpIGFjY2VwdGFibGUgdG8gdGhlIFJTLg0KVGhlbiB0aGUgY2xp ZW50IG1heSBpbmRpY2F0ZSB0byB0aGUgQVMgdGhlc2UgYWNjZXB0YWJsZSBmb3JtYXRzLiBJZiB0 aGUgUlMgYW5kIHRoZSBBUyBoYXZlIGFuIGFjY2VzcyB0b2tlbiBmb3JtYXQgaW4gY29tbW9uLCB0 aGVuIHRoZSBwcm9jZXNzIG1heSBjb250aW51ZS4NCg0KV2hlbiBvbmx5IGF0dHJpYnV0ZXMgKGku ZS4gbm90IHJpZ2h0cykgYXJlIGJlaW5nIHJlcXVlc3RlZCB0byBhbiBBUyBieSB0aGUgY2xpZW50 LCB0aGUgY2xpZW50IGRvZXMgbm90IG5lZWQgdG8gZGlzY2xvc2UgdGhlIGlkZW50aXR5IG9mIHRo ZSBSUyB0byB0aGUgQVMsDQp3aGljaCBoYXMgdGhlIG1ham9yIGFkdmFudGFnZSB0byBwcmV2ZW50 IHRoZSBBUyB0byBhY3QgYXMgQmlnIEJyb3RoZXIuDQoNCiAgICBOb3RlOiB0aGlzIGRvZXMgbm90 IHByZWNsdWRlIHRoZSB1c2Ugb2YgcmlnaHRzLCBpbiBwYXJ0aWN1bGFyIGluIHRoZSBjb250ZXh0 IG9mIGEgc2luZ2xlIG9yZ2FuaXphdGlvbiBvciBlbnRlcnByaXNlLg0KDQpEZW5pcw0KDQog4oCU IEp1c3Rpbg0KDQpPbiBGZWIgMjEsIDIwMjEsIGF0IDk6NDAgQU0sIEFkcmlhbiBHcm9wcGVyIDxh Z3JvcHBlckBoZWFsdGh1cmwuY29tPG1haWx0bzphZ3JvcHBlckBoZWFsdGh1cmwuY29tPj4gd3Jv dGU6DQoNCkhpIFRvcnN0ZW4sDQoNClRoYW5rIHlvdSBmb3IgcmFpc2luZyBhbGwgb2YgdGhlc2Ug ZXhjZWxsZW50IHBvaW50cy4gSSBob3BlIHdlIGNhbiBhbGwgYW5zd2VyIHRoZW0gYW5kIG1heWJl IGV2ZW4gYWRkIGEgc2VjdGlvbiB0byB0aGUgd2lraS4gSSdsbCBzdGFydC4uLg0KDQpZb3UncmUg cmlnaHQgdGhhdCBPQXV0aCBkZXBsb3ltZW50cyBhbG1vc3QgZXhjbHVzaXZlbHkgcHV0IHRoZSBB UyBhbmQgUlMgaW4gdGhlIHNhbWUgZG9tYWluLiBJZiBPQXV0aCB3ZXJlIGFkZXF1YXRlIHRvIHRv ZGF5J3MgbmVlZHMgd2UgcHJvYmFibHkgd291bGQgbm90IGJlIGhlcmUgZG9pbmcgR05BUC4gU2lu Y2UgT0F1dGgsIHdlIGhhdmUgaW5jcmVhc2luZyBwcml2YWN5IGNvbmNlcm5zIGFuZCBzZWN1cml0 eSBkaXNhc3RlcnMuIEdEUFIsIGZvciBleGFtcGxlLCBzZXBhcmF0ZXMgdGhlIHJvbGUgb2YgYSBk YXRhIGNvbnRyb2xsZXIgZnJvbSBhIGRhdGEgcHJvY2Vzc29yIGFuZCB0cmVhdHMgdGhlbSBhcyBz ZXBhcmF0ZSBsZWdhbCBlbnRpdGllcy4gVG8gb3ZlcnNpbXBsaWZ5IEdEUFIsIHRoZSBkYXRhIHBy b2Nlc3NvciBpcyBzcGFyZWQgcHJpdmFjeSByZXNwb25zaWJpbGl0eSBhbmQgY29zdC4NCg0KWW91 IGFyZSBhbHNvIHJpZ2h0IHRvIG1lbnRpb24gb3BlbiBiYW5raW5nIGFzIGEgdXNlLWNhc2UuIE9w ZW4gYmFua2luZyBoYXMgbm90IGFkb3B0ZWQgVU1BIDIuMCAob24gd2hpY2ggSSBoYXZlIHdvcmtl ZCBmb3IgYWxtb3N0IGEgZGVjYWRlKSB3aGljaCBpcyBiYXNlZCBvbiBPQXV0aC4gUFNEMiBhbmQg c2ltaWxhciByZWd1bGF0aW9ucyBkbyBub3QgdGllIHRoZSBBUyBhbmQgUlMgdG8gdGhlIHNhbWUg c2VjdXJpdHkgZG9tYWluIGJ1dCB0aGV5IHByZXN1bWUgYSBuYXJyb3cgZmVkZXJhdGlvbiBvZiBs aWNlbnNlZCAoYW5kIHJlZ3VsYXRlZCkgQVNzIGFzIHBheW1lbnQgcHJvY2Vzc29ycyBmb3Igc3Vi amVjdHMgdG8gY2hvb3NlIGFtb25nLiBUaGlzIGNlbnRyYWxpemF0aW9uIHRvIHJlZ3VsYXRlZCBm aWR1Y2lhcmllcyBpcyBhIHByaXZhY3kgdHJhZGUtb2ZmIHRoYXQgbWFrZXMgc2Vuc2UgaW4gYmFu a2luZy4gVGhlIGZpZHVjaWFyeSBjYW4gYmUgYm9uZGVkIHNvIHRoZXkgY2FuIHJlZnVuZCB0aGUg bW9uZXkgdG8gdGhlIHN1YmplY3QgaW4gY2FzZSBvZiBhIHNlY3VyaXR5IGJyZWFjaC4gVGhpcyBw cml2YWN5LXNlY3VyaXR5IHRyYWRlb2ZmIGRvZXMgbm90IG1ha2Ugc2Vuc2UgaW4gaGVhbHRoY2Fy ZSBhbmQgb3RoZXIgZG9tYWlucyB3aGVyZSB0aGUgY29uc2VxdWVuY2VzIG9mIGEgYnJlYWNoIGFy ZSBub3QgZWFzaWx5IHJldmVyc2VkLg0KDQpUaGlzIHRocmVhZCBpcyBhYm91dCBhbGlnbmluZyBH TkFQIGFuZCBTU0kuIFNTSSBkb2VzIG5vdCBhYmlkZSBjZW50cmFsaXphdGlvbiwgY2Vuc29yc2hp cCwgb3Igc3VydmVpbGxhbmNlLiBJZiBHTkFQIG1ha2VzIGFueSBhc3N1bXB0aW9ucyB0aGF0IHJl c3VsdCBpbiBlaXRoZXIgYSB0aWdodCBjb3VwbGluZyBiZXR3ZWVuIEFTIGFuZCBSUyAoc3VydmVp bGxhbmNlKSBvciBldmVuIGEgZmVkZXJhdGVkIGZpZHVjaWFyeSAoY2VudHJhbGl6YXRpb24pIHdl IHdpbGwgbG9zZSBvdXQgb24gdGhlIGJlbmVmaXRzIG9mIHByb2dyZXNzIGluIGRpZ2l0YWwgaWRl bnRpdHkgdGhhdCBpcyBub3cgZHJpdmluZyBhIGxvdCBvZiBwdWJsaWMtc2VjdG9yIGluaXRpYXRp dmVzIGFuZCBzdGFydGluZyB0byBibGVlZCBvdmVyIGludG8gcHJpdmF0ZSBzZWN0b3IgcHJhY3Rp Y2VzLiBaZXJvIFRydXN0IEFyY2hpdGVjdHVyZSBpcyBhbiBleGFtcGxlIGFuZCBPQXV0aCBpcyBu b3Qgd2VsbCBzdWl0ZWQgZm9yIFpUQS4NCg0KQXMgeW91IHNhaWQsICJ0ZWNobmljYWxseSwgdGhl IHJlc3BlY3RpdmUgQVMgYW5kIFJTcyBzZXQgdXAgYSB0cnVzdCByZWxhdGlvbnNoaXAgYW5kIGFn cmVlZCBvbiB3YXlzIHRvIHNoYXJlIGF1dGhvcml6YXRpb24gYW5kIHVzZXIgZGF0YSBpbiBvcmRl ciBbdG9dIGVuYWJsZSBzZWN1cmUgQVBJIGFjY2Vzcy4iIFRoaXMgaXMgd2hlcmUgR05BUCBvcGVy YXRlcyBhbmQgd2UgbmVlZCB0byBhdm9pZCBfYW55XyByZXN0cmljdGlvbnMgb24gZWl0aGVyIHRo ZSBBUyBvciB0aGUgUlMgYmVpbmcgc2VsZi1zb3ZlcmVpZ24uIEV4YW1wbGVzIG9mIGEgc2VsZi1z b3ZlcmVpZ24gUlMgY291bGQgYmUgYSBwZXJzb25hbCBkYXRhIHN0b3JlIG9yIGFuIGVuY3J5cHRl ZCBkYXRhIHZhdWx0IGxpa2UgdGhlIG9uZXMgd2Ugd29yayBvbiBpbiBXM0MvRElGLiBBbnkgQVMg Y2FuIGJlIHNlbGYtc292ZXJlaWduIGlmIHRoZSBzdWJqZWN0IGNvbnRyb2xzIGFsbCBvZiB0aGUg cG9saWNpZXMgYW5kIHRoZXNlIHBvbGljaWVzIGFyZSBub3Qgc2hhcmVkLCBpbiB0aGUgc2FtZSB3 YXkgYSBwcml2YXRlIGtleSBpcyBuZXZlciBub3Qgc2hhcmVkLg0KDQpDb250aW51aW5nIHlvdXIg cXVvdGU6DQpJIHJlYWQgeW91ciBpZGVhcyByZWdhcmRpbmcgc2VsZi1zb3ZlcmVpZ24gQVNzIHdp dGggZ3JlYXQgaW50ZXJlc3QgYW5kIGdvdCBzb21lIG9ic2VydmF0aW9ucy9xdWVzdGlvbnM6DQot IEEgcGVyc29uYWwgQVMgY291bGQgY2VydGFpbmx5IGNvbnRyb2wgYWNjZXNzIHRvIGEgcGVyc29u 4oCYcyByZXNvdXJjZXMuIEkgYXNzdW1lIHRoZSBwZXJzb27igJhzIFJTcyB3b3VsZCBvbmx5IGFj Y2VwdCBhY2Nlc3MgdG9rZW5zIHNpZ25lZCBieSB0aGUgUk8uIEFtIEkgcmlnaHQ/DQpZZXMsIGFu ZC4gVGhlcmUgaXMgZGViYXRlIGluIHZhcmlvdXMgU1NJIFdHcyB3aGV0aGVyIGEgUlMgc3VjaCBh cyBhbiBFbmNyeXB0ZWQgRGF0YSBWYXVsdCBzaG91bGQgcmVzcG9uZCB0byBjYXBhYmlsaXRpZXMg b3IgdG9rZW5zLiBFaXRoZXIgd2F5LCB0aGUgUk8gaXMgaW4gY29udHJvbCBvZiB0aGUgc2lnbmF0 dXJlIGJ1dCBhIHBlcnNvbmFsIEFTIGlzIGEgZGVsZWdhdGUgb2YgdGhlIFJPIChlaXRoZXIgZGly ZWN0bHkgb3IgdmlhIGEgbW9iaWxlIHVzZXIgYWdlbnQpLiBXaXRoIGNhcGFiaWxpdGllcyBzdWNo IGFzIFpDQVAtTEQgb3IgYmlzY3VpdHMsIHRoZSB0b2tlbiBzaWduYXR1cmUgYWxsb3dzIGZvciBm aWx0ZXJlZCBkZWxlZ2F0aW9uLg0KDQotIERvIHlvdSBlbnZpc2lvbiB0aGlzIEFTIHRvIGJlIGFi bGUgdG8gY29udHJvbCBhY2Nlc3MgdG8gYW55IGtpbmQgb2YgUlM/IEhvdyBpcyB0aGUgQVMgc3Vw cG9zZWQgdG8ga25vdyB3aGF0IGF1dGhvcml6YXRpb24gZGF0YSB0aGlzIFJTIG5lZWRzIGluIG9y ZGVyIHRvIHBlcmZvcm0gYWNjZXNzIGNvbnRyb2wgZGVjaXNpb25zPyBXaGF0IGRhdGEgd2lsbCBi ZSBleGNoYW5nZWQ/DQpZZXMuIFRoZSB3aG9sZSBwb2ludCwgYXMgZmFyIGFzIEknbSBjb25jZXJu ZWQsIGlzIHRvIGRlc2lnbiBodW1hbiBjZW50ZXJlZCBzdGFuZGFyZHMuIFRoaXMgaXMgaG93IFcz QyBhbmQgSUVURiBhcmUgZGlmZmVyZW50LiBPdGhlciBTRE9zIHRlbmQgdG8gYmUgb3BlcmF0ZWQg Zm9yIGluc3RpdHV0aW9uYWwgYmVuZWZpdC4gQSBwZXJzb24tY2VudGVyZWQgQVMgbXVzdCB3b3Jr IGFjcm9zcyBpbnN0aXR1dGlvbmFsIGRvbWFpbnMuDQoNClRoaXMsIGFzIHlvdSBwb2ludCBvdXQs IGJyaW5ncyB1cCB0aGUgcHJvYmxlbSBvZiBzY29wZS4gT250b2xvZ2llcyBhbmQgZGF0YSBtb2Rl bHMgYXJlLCBqdXN0aWZpYWJseSwgZG9tYWluLXNwZWNpZmljLiBJLCBmb3IgZXhhbXBsZSwgd29y ayBhcm91bmQgdGhlIEhMNyBkYXRhIG1vZGVsIHN0YW5kYXJkcyBhbmQgQVBJcyBsaWtlIEZISVIg dGhhdCBhcmUgY29udHJvbGxlZCBieSBoZWFsdGhjYXJlIGJ1c2luZXNzIGludGVyZXN0cy4gSXQn cyB1bnJlYXNvbmFibGUgdG8gZXhwZWN0IGEgZ2VuZXJhbCBzb2x1dGlvbiB0byB0aGUgZGF0YSBt b2RlbCBwcm9ibGVtLCBhbHRob3VnaCBmb2xrcyBvZiB0aGUgTGlua2VkIERhdGEgcGVyc3Vhc2lv biBtaWdodCBkaXNhZ3JlZS4NCg0KRXZlcnkgUlMgZ2V0cyB0byBkZWNpZGUgd2hhdCBkYXRhIG1v ZGVscyBhbmQgb250b2xvZ2llcyBpdCBzdXBwb3J0cy4gVGhlc2UgZGVjaXNpb25zIGFyZSBwdWJs aWMgYW5kIHNvbWV0aW1lcyBzdGFuZGFyZGl6ZWQgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBjbGll bnRzLiBBIHBlcnNvbidzIEFTIG11c3QgcmVhZCBhbmQgbWF5YmUgdW5kZXJzdGFuZCB0aGUgUlMg ZGF0YSBtb2RlbCBpbiBvcmRlciB0byBpc3N1ZSB0b2tlbnMganVzdCBsaWtlIHRoZSBjbGllbnQg bmVlZHMgdG8gZG8gaW4gb3JkZXIgdG8gbWFrZSBhIHJlcXVlc3QgdG8gdGhlIEFTLiBJbiBvdXIg SElFIG9mIE9uZSBUcnVzdGVlIHByb2plY3QsIHdlIGFsbG93IHRoZSBzZWxmLXNvdmVyZWlnbiBz dWJqZWN0IHRvIGluaGVyaXQgQVMgcG9saWNpZXMgZnJvbSBzZWxmLXNvdmVyZWlnbiBjb21tdW5p dGllcyB0aGV5IGNob29zZSBhbmQgdGhlbiBtb2RpZnkgdGhlIHBvbGljaWVzIGlmIHRoZXkgd2Fu dC4gSW4gdGhpcyB3YXksIGNvbW11bml0aWVzIGNvbXBldGUgZm9yIG1lbWJlcnMgb24gdGhlIGJh c2lzIG9mIHBvbGljeSBidW5kbGVzIHRoZSBzYW1lIHdheSBjaHVyY2hlcyBjb21wZXRlIGZvciBj b25ncmVnYW50cy4NCg0KLSBIb3cgd291bGQgdGhpcyBwZXJzb24gZGVsZWdhdGUgYWNjZXNzIHRv IGhlciByZXNvdXJjZXMgdG8gc29tZW9uZSBlbHNlPw0KVGhlcmUgYXJlIHR3byAicGVyc29ucyIg dG8gY29uc2lkZXIuIFRoZSBSTyBkZWxlZ2F0ZXMgdG8gYW4gUlEuIEJ1dCB0aGUgUlEsIGluIHJl YWwgbGlmZSwgaXMgcGFydCBvZiBhIHRlYW0gYW5kIG9mdGVuIGRlbGVnYXRlcyB0byBhc3NvY2lh dGVzLiBXaXRoIG9yIHdpdGhvdXQgY2FwYWJpbGl0aWVzLCBHTkFQIG5lZWRzIHRvIGRlYWwgd2l0 aCB0aGlzIHJlYWxpdHkgdGhhdCBSTyBhbmQgUlEgdXNlciBhZ2VudHMgbWF5IGJlIGRpZmZlcmVu dCBmcm9tIHRoZSBjbGllbnQgdGhhdCBhY3R1YWxseSBwcmVzZW50cyBhIHRva2VuIHRvIHRoZSBS Uy4gU29tZSBvZiB0aGlzIGRpZmZlcmVuY2UgYmV0d2VlbiB1c2VyIGFnZW50cyBhbmQgY2xpZW50 cyB3ZSBtYXkgYmUgYWJsZSB0byBrZWVwIG91dCBvZiBiYW5kLg0KDQotIEFyZSB5b3UgYXdhcmUg b2YgZGVwbG95bWVudHMgaW1wbGVtZW50aW5nIHRoaXMgcGhpbG9zb3BoeT8NCk90aGVyIHRoYW4g b3VyIEhJRSBvZiBPbmUgZGVtb25zdHJhdGlvbiBwcm9qZWN0IGluIGhlYWx0aGNhcmUsIG5vLiBX ZSBzdGFydGVkIEhJRSBvZiBPbmUgYmVmb3JlIFNTSSBpbiBvcmRlciB0byBkcml2ZSB0aGUgdHJh bnNpdGlvbiBmcm9tIFVNQSB0byBVTUEgMi4wIGFuZCBpbmZvcm0gdmFyaW91cyBoZWFsdGhjYXJl IHJlZ3VsYXRvcnkgcHJpb3JpdGllcy4gV2UgdGhlbiBqdW1wZWQgb24gU1NJIGltbWVkaWF0ZWx5 IGFuZCBhZGRlZCBpdCB0byB0aGUgVU1BIDIgQVMgd2UgY2FsbCBUcnVzdGVlLiBOb3cgd2UgYXJl IHRyeWluZyB0byBhbGlnbiBTU0kgYW5kIEdOQVAgaW4gb3JkZXIgdG8gZW5hYmxlIGh1bWFuLWNl bnRlcmVkIHByb3RvY29scyBhbmQgemVyby10cnVzdCBhcmNoaXRlY3R1cmUuDQoNCi0gV2hhdCBh cmUgdGhlIGltcGxpY2F0aW9ucyBpbiB0ZXJtcyBvZiB1c2VyIGV4cGVyaWVuY2U/DQpSaWdodCBu b3csIHRoZSBodW1hbi1jZW50ZXJlZCB1c2VyIGV4cGVyaWVuY2UgYXNzdW1lcyBhIHNlY3VyZSBl bGVtZW50IGFuZCB3ZWIgYnJvd3NlciBhcyB1c2VyIGFnZW50cyBvbiBhIG1vYmlsZSBkZXZpY2Uu IE5laXRoZXIgb2YgdGhlc2UgaXMgcmVhZGlseSBhY2Nlc3NpYmxlIGFzIGEgc2VydmVyIG5vciBh cmUgdGhleSBkZXNpZ25lZCB0byBhY2NlcHQgY29kZSBwbHVnLWlucyB0aGF0IHJlcHJlc2VudCB0 aGUgcG9saWNpZXMgb2YgYW4gQVMuIE9uZSBtYWpvciBleGNlcHRpb24gaXMgcGVvcGxlIGFkZGlu ZyBhZHZlcnRpc2luZyBhbmQgc3VydmVpbGxhbmNlIGJsb2NrZXJzIGxpa2UgRUZGIFByaXZhY3kg QmFkZ2VyIHRvIHRoZWlyIGJyb3dzZXIuDQoNClRoZSB1c2VyIGV4cGVyaWVuY2UgaW1wbGljYXRp b25zIG9mIGhhdmluZyBTU0kgZGF0YSBtb2RlbCBzdGFuZGFyZHMgYW5kIEdOQVAgcHJvdG9jb2wg c3RhbmRhcmRzIGlzIHRoYXQgdG9kYXkncyBwYXNzd29yZCBtYW5hZ2VycyAoSSBoYXZlIDI1MCBS UyByZWxhdGlvbnNoaXBzIGluIG1pbmUpIHdpbGwgZXZvbHZlIHRvIGFsc28gY29udHJvbCBhbiBB UyBhZ2VudC4gSnVzdCBsaWtlIEkgbWlnaHQgcmVnaXN0ZXIgYSBXM0MgRElEIHdpdGggYW4gUlMg aW5zdGVhZCBvZiBhbiBlbWFpbCBhZGRyZXNzLCBteSBwb2xpY3kgbWFuYWdlciBtaWdodCBkaXNw bGF5IHRvIG1lIHRoZSB0b2tlbiBwb2xpY2llcyB0aGF0IHdpbGwgYmUgYXBwbGllZCBieSBteSBB UyB0byB0aGUgcGVyc29uYWwgZGF0YSBJIGNhbiBjb250cm9sIGF0IHRoYXQgUlMuDQoNCkluIHNv bWUgY2FzZXMsIG15IEFTIHdpbGwgYWxsb3cgbWUgdG8gbW9kaWZ5IHRob3NlIHBvbGljaWVzIGp1 c3QgbGlrZSB0aGUgb2Jub3hpb3VzIGNvb2tpZSBwb2xpY3kgc2V0dGluZ3MgZG8gdG9kYXkuIFRo ZSBCSUcgZGlmZmVyZW5jZSB3aXRoIEdOQVAgaXMgdGhhdCBJIGNob29zZSBteSBBUyBzZXBhcmF0 ZWx5IGZyb20gdGhlIFJTIHNvIHRoZSBkYXJrIHBhdHRlcm5zIGFzc29jaWF0ZWQgd2l0aCB0b2Rh eSdzIGNvb2tpZSBwb2xpY2llcyBleHBlcmllbmNlIGFyZSBubyBsb25nZXIgcG9zc2libGUuIEdO QVAgbWVhbnMgdGhlIFJTIGV4cG9zZXMgYW4gQVBJIHJhdGhlciB0aGFuIGEgVUkuDQoNCkkndmUg Z29uZSBvbiBmYXIgdG9vIGxvbmcgdG8gYWRkcmVzcyB0aGUgaXNzdWUgb2YgdGhlIEFTIGFzIGFu IGlkZW50aXR5IHByb3ZpZGVyLiBJdCdzIGZhaXIgdG8gdGhpbmsgb2YgaXQgdGhhdCB3YXkuIEFz IGl0IHR1cm5zIG91dCwgaW4gdGhlIFNTSSBTZWN1cmUgRGF0YSBTdG9yYWdlIFdHLCB3ZSBhcmUg ZGViYXRpbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhbiBFbmNyeXB0ZWQgRGF0YSBWYXVsdCBh bmQgYW4gSWRlbnRpdHkgSHViLiBBcyBmYXIgYXMgSSdtIGNvbmNlcm5lZCwgdGhlIElkZW50aXR5 IEh1YiBpcyBtb3N0bHkgYSBHTkFQIEFTLiBKb2luIHVzIG9uIFRodXJzZGF5cyBhdCA0IFBNIEVU IGh0dHBzOi8vbGlzdHMuaWRlbnRpdHkuZm91bmRhdGlvbi9nL3Nkcy13Zy93aWtpL0hvbWUNCg0K QWRyaWFuDQoNCg0KDQpPbiBTdW4sIEZlYiAyMSwgMjAyMSBhdCA0OjM0IEFNIFRvcnN0ZW4gTG9k ZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldD4+IHdyb3RlOg0KDQoNCkFtIDE5LjAyLjIwMjEgdW0gMjM6NTAgc2NocmllYiBBZHJp YW4gR3JvcHBlciA8YWdyb3BwZXJAaGVhbHRodXJsLmNvbTxtYWlsdG86YWdyb3BwZXJAaGVhbHRo dXJsLmNvbT4+Og0KDQrvu78NCkkgYWdyZWUgd2l0aCB0aGUgZmlyc3QgdHdvIG9mIEp1c3Rpbidz IHJlc3BvbnNlcyBidXQgbm90IHRoZSBsYXN0IG9uZS4NCg0KSXQncyBjb25mdXNpbmcgdG8gdGhp bmsgdGhhdCB0aGVyZSBhcmUgbW9yZSBSUyB0aGFuIEFTLg0KDQp0aGUgT0F1dGggZGVwbG95bWVu dHMgSeKAmG0gYXdhcmUgb2YgdHlwaWNhbGx5IGhhdmUgbXVjaCBtb3JlIFJTcyB0aGFuIEFTcy4g V2h5PyBCZWNhdXNlIEFTIGFuZCBhIHNldCBvZiBSU3MgYmVsb25nIHRvIHRoZSBzYW1lIHNlY3Vy aXR5IGRvbWFpbiAoZS5nLiBhIGNlcnRhaW4gYnVzaW5lc3MpIGFuZCBpdOKAmXMgdGhlIEFT4oCZ cyByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgc2VjdXJlIGFuZCBjb252ZW5pZW50IGFjY2VzcyB0 byB0aGUgQVBJcyBwcm92aWRlZCBieSB0aGlzIFJTcy4gRm9yIGV4YW1wbGU6IHRoZXJlIGlzIGEg QVMgY29udHJvbGxpbmcgYWNjZXNzIHRvIGEgY2xvdWQsIHN0cmVhbWluZywgYW5kIG1lc3NhZ2lu ZyBzZXJ2aWNlcyBvZiB0aGUgc2FtZSBidXNpbmVzcy4gSW4gY2FzZSBvZiBvcGVuIGJhbmtpbmcs IHRoZSBiYW5r4oCYcyBBUyBpcyAob24gYmVoYWxmIG9mIHRoZSB1c2VyKSBhdXRob3JpemluZyBh Y2Nlc3MgdG8gQVBJcyBmb3IgYWNjb3VudCBpbmZvcm1hdGlvbiBhcyB3ZWxsIGFzIHBheW1lbnQg aW5pdGlhdGlvbiBhbmQgcG90ZW50aWFsbHkgb3RoZXIgc2VydmljZXMuDQoNClRlY2huaWNhbGx5 LCB0aGUgcmVzcGVjdGl2ZSBBUyBhbmQgUlNzIHNldCB1cCBhIHRydXN0IHJlbGF0aW9uc2hpcCBh bmQgYWdyZWVkIG9uIHdheXMgdG8gc2hhcmUgYXV0aG9yaXphdGlvbiBhbmQgdXNlciBkYXRhIGlu IG9yZGVyIGVuYWJsZSBzZWN1cmUgQVBJIGFjY2Vzcy4NCg0KSSByZWFkIHlvdXIgaWRlYXMgcmVn YXJkaW5nIHNlbGYtc292ZXJlaWduIEFTcyB3aXRoIGdyZWF0IGludGVyZXN0IGFuZCBnb3Qgc29t ZSBvYnNlcnZhdGlvbnMvcXVlc3Rpb25zOg0KLSBBIHBlcnNvbmFsIEFTIGNvdWxkIGNlcnRhaW5s eSBjb250cm9sIGFjY2VzcyB0byBhIHBlcnNvbuKAmHMgcmVzb3VyY2VzLiBJIGFzc3VtZSB0aGUg cGVyc29u4oCYcyBSU3Mgd291bGQgb25seSBhY2NlcHQgYWNjZXNzIHRva2VucyBzaWduZWQgYnkg dGhlIFJPLiBBbSBJIHJpZ2h0Pw0KLSBEbyB5b3UgZW52aXNpb24gdGhpcyBBUyB0byBiZSBhYmxl IHRvIGNvbnRyb2wgYWNjZXNzIHRvIGFueSBraW5kIG9mIFJTPyBIb3cgaXMgdGhlIEFTIHN1cHBv c2VkIHRvIGtub3cgd2hhdCBhdXRob3JpemF0aW9uIGRhdGEgdGhpcyBSUyBuZWVkcyBpbiBvcmRl ciB0byBwZXJmb3JtIGFjY2VzcyBjb250cm9sIGRlY2lzaW9ucz8gV2hhdCBkYXRhIHdpbGwgYmUg ZXhjaGFuZ2VkPw0KLSBIb3cgd291bGQgdGhpcyBwZXJzb24gZGVsZWdhdGUgYWNjZXNzIHRvIGhl ciByZXNvdXJjZXMgdG8gc29tZW9uZSBlbHNlPw0KLSBBcmUgeW91IGF3YXJlIG9mIGRlcGxveW1l bnRzIGltcGxlbWVudGluZyB0aGlzIHBoaWxvc29waHk/DQotIFdoYXQgYXJlIHRoZSBpbXBsaWNh dGlvbnMgaW4gdGVybXMgb2YgdXNlciBleHBlcmllbmNlPw0KDQpJbiBteSBleHBlcmllbmNlIGNv dXBsaW5nIGJldHdlZW4gQVMgYW5kIFJTIGlzIHZlcnkgdGlnaHQuIEkgaGF2ZSBhIGhhcmQgdGlt ZSB0byBzZWUgaG93IHNlbGYtc292ZXJlaWduIEFTcyB3b3VsZCB3b3JrLiBJdCBmZWVscyBsaWtl IHN1Y2ggYW4gQVMgaW4gdGhlIGVuZCBpcyBhbiBpZGVudGl0eSBwcm92aWRlciBvZiBzb21lIHNv cnQsIHdoaWNoIGJyaW5ncyBtZSB0byB3aGF0IEp1c3RpbiBwcm9wb3NlZC4gSSB3b3VsZCBhc3N1 bWUgdXNpbmcgU1NJIGNyZWRlbnRpYWxzIHRvIGF1dGhlbnRpY2F0ZSB0b3dhcmRzIEFTcyBpcyBm ZWFzaWJsZSBhbmQgbWlnaHQgaGF2ZSB2YWx1ZSBidXQgSeKAmG0gc2tlcHRpY2FsIGFib3V0IHRo ZSBBUyBwYXJ0Lg0KDQpiZXN0IHJlZ2FyZHMsDQpUb3JzdGVuLg0KDQpGcm9tIGEgaHVtYW4tY2Vu dGVyZWQgKGFuZCBob3BlZnVsbHkgSUVURikgcGVyc3BlY3RpdmUsIGVhY2ggcGVyc29uIG1pZ2h0 IGNvbnRyb2wgb3Igc3BlY2lmeSBhIGRpZmZlcmVudCBBUyBmb3IgZWFjaCBvZiB0aGVpciBwZXJz b25hcyBvciBmb3IgZWFjaCBjaGlsZCBvciBpbmNvbXBldGVudCBkZWxlZ2F0ZSBvZiB0aGVtIGFz IGd1YXJkaWFuLiBXZSdyZSBmYW1pbGlhciB3aXRoIHNlcGFyYXRlIGdtYWlsIGFkZHJlc3NlcyBm b3IgZWFjaCBwZXJzb25hLg0KDQpBU3Mgd2lsbCBiZSBzZWxmLXNvdmVyZWlnbiAoYXMgaW4gU1NJ KSwgZmlkdWNpYXJ5IChhcyBpbiBhIGN1c3RvZGlhbCBiaXRjb2luIHdhbGxldCksIG9yIGJyb2tl cnMgKGFzIGluIGRhdGEgYnJva2VycyBhbmQgc3VydmVpbGxhbmNlIGNhcGl0YWxpc20pLiBBbnkg UlMgdGhhdCBpcyB3aWxsaW5nIHRvIGhhdmUgYSByZWN1cnJpbmcgcmVsYXRpb25zaGlwIHdpdGgg YSBwZXJzb25hIGNvdWxkIGFjY2VwdCBhIEdOQVAgQVMgZW5kcG9pbnQgaW5zdGVhZCBvZiBhbiBl bWFpbCBhZGRyZXNzLiBUaGlzIGlzIGVhc2llc3QgdXNpbmcgSFRUUCwgYnV0IEdOQVAgbmVlZCBu b3QgZXhjbHVkZSBvdGhlciBSUyAvIEFTIEFQSXMgYW5kIHRyYW5zcG9ydHMuIERlc2lnbmluZyBh cm91bmQgdGhlIHVuY2Vuc29yZWQgc3BlY2lmaWNhdGlvbiBvZiBvbmUncyBBUyBhcyBhIGh1bWFu IHJpZ2h0IHdvdWxkIGdyZWF0bHkgc2ltcGxpZnkgbWFueSBhc3BlY3RzIG9mIEdOQVAgYWRvcHRp b24uDQoNClRoYXQgc2FpZCwgR05BUCBzaG91bGQgbm90IGlnbm9yZSB0aGUgUlMgYnVzaW5lc3Mg b3IganVyaXNkaWN0aW9uYWwgcmVhc29ucyB0byBsaW1pdCB0aGUgYXV0aG9yaXR5IG9mIHRoZSBB Uy4gVU1BIDIuMCBzcGVudCB5ZWFycyBkYW5jaW5nIGFyb3VuZCB0aGlzIGlzc3VlIHdpdGggaWRl YXMgbGlrZSAiY2FzY2FkaW5nIiBBUyBhbmQgdmFyaW91cyBjZW50cmFsaXplZCBvciBmZWRlcmF0 ZWQgQVMgY29uY2VwdHMuIE15IGNvbmNsdXNpb24gaXMgdGhhdCBhbnkgUlMgY2FuIGFsd2F5cyBk byB3aGF0ZXZlciBpdCB3YW50cyBhbmQgdGhlcmUncyBub3QgbXVjaCB0aGUgYXV0aG9yaXphdGlv biBwcm90b2NvbCBjYW4gaGVscCB3aXRoIG90aGVyIHRoYW4gc3BlY2lmeWluZyBhIG5vdGlmaWNh dGlvbiBlbmRwb2ludCBzbyB0aGF0IGFuIFJTIGNhbiB3YXJuIChhbmQgc2VlayBjb25maXJtYXRp b24pIG9yIGxvZyB2YXJpb3VzIGV4Y2VwdGlvbnMuIFRoaXMgdHVybnMgb3V0IHRvIGJlLCBhZnRl ciBhIHllYXIgb2YgdGVzdGltb255LCB0aGUgcmVndWxhdGlvbiB0aGF0IGFwcGxpZXMgdG8gSElQ QUEgUlMgQVBJcyBpbiB0aGUgVVMuIEZvciB0aGlzIHJlYXNvbiBHTkFQIG1pZ2h0IGluY2x1ZGUg YSBub3RpZmljYXRpb24gcHJvdG9jb2wgaW4gdGhlIEFTIHNwZWNpZmljYXRpb24sIG9yIG5vdC4N Cg0KSSBwcm9wb3NlIHRoYXQgZW1icmFjaW5nIGEgc2VsZi1zb3ZlcmVpZ24gYWdlbnQgaXMga2V5 IHRvIGhhcm1vbml6aW5nIHRoZSBTU0kgYW5kIEdOQVAgc3RhbmRhcmRzLg0KDQpBZHJpYW4NCg0K T24gRnJpLCBGZWIgMTksIDIwMjEgYXQgMjozMCBQTSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1p dC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KVG9iaWFzLCB0aGFua3MgZm9y IHRoZSBncmVhdCBvYnNlcnZhdGlvbnMuIFNvbWUgcmVhY3Rpb25zIGlubGluZSBiZWxvdy4NCg0K T24gRmViIDE4LCAyMDIxLCBhdCA3OjU5IFBNLCBUb2JpYXMgTG9va2VyIDx0b2JpYXMubG9va2Vy QG1hdHRyLmdsb2JhbDxtYWlsdG86dG9iaWFzLmxvb2tlckBtYXR0ci5nbG9iYWw+PiB3cm90ZToN Cg0KSnVzdGluLA0KDQpJIHRoaW5rIHRoaXMgaXMgYSBncmVhdCBhbmQgdGltZWx5IGNvbnZlcnNh dGlvbiB0byBiZSBoYXZpbmcgZ2l2ZW4gdGhlIGN1cnJlbnQgaW50ZXJlc3QgYXJvdW5kIFNTSSBh bmQgZWZmb3J0cyBsaWtlIFNJT1AsIEkgaGF2ZSBiZWVuIGRvaW5nIHF1aXRlIGEgYml0IG9mIHdv cmsgaW4gdGhpcyBzcGFjZSBhcyBvZiByZWNlbnQsIHNvIHRob3VnaHQgSSdkIGFkZCBhIGZldyBv ZiB0aGUgb2JzZXJ2YXRpb25zIHRoYXQgSSd2ZSBtYWRlLg0KDQpJbiBteSBvcGluaW9uIFNJT1Ag d2FzIHJlYWxseSBhIGJ1Y2tldCBmb3Igc29sdmluZyBxdWl0ZSBhIGZldyBkaWZmZXJlbnQgcHJv YmxlbXMsIG5vdCBqdXN0IG9uZS4gSW4gcGFydGljdWxhciBJIHRoaW5rIGl0cyBpbnRlbnQgd2Fz IHRvIHNvbHZlIDMgbWFqb3Igb25lczoNCg0KMS4gRW5hYmxpbmcgcG9ydGFibGUgaWRlbnRpdGll cw0KMi4gU29sdmluZyB0aGUgTkFTQ0FSIHByb2JsZW0NCjMuIEV4cGxvcmluZyBkaWZmZXJlbnQg ZGVwbG95bWVudCBtb2RlbHMgZm9yIHRoZSBwcm92aWRlcg0KDQpUbyBkcmlsbCBkb3duIGJyaWVm bHkgb24gdGhlc2UsIG5vdGUgbXVjaCBvZiBteSB0ZXJtaW5vbG9neSBpcyBPcGVuSUQgYmFzZWQg ZHVlIHRvIFNJT1BzIG9yaWdpbg0KDQpFbmFibGluZyBwb3J0YWJsZSBpZGVudGl0aWVzIC0gSW4g Z2VuZXJhbCB0b2RheSBpbiB0aGUgY2FzZSBvZiBPcGVuSUQsIHRoZSBlbmQtdXNlcnMgaWRlbnRp dHkgYXMgdW5kZXJzdG9vZCBieSBhIHJlbHlpbmcgcGFydHkgaXMgc2NvcGVkIHdpdGhpbiB0aGUg ZG9tYWluIG9mIHRoZSBwcm92aWRlci4gV2hpY2ggbWVhbnMgaWYgdGhhdCBwcm92aWRlciBnb2Vz IG91dCBvZiBidXNpbmVzcyBvciBmb3Igd2hhdGV2ZXIgcmVhc29uIGRlY2lkZXMgdG8gbm8gbG9u Z2VyIG9mZmVyIHRoZSBzYW1lIGlkZW50aXR5IHNlcnZpY2VzIHRvIHRoZSBFbmQtVXNlciwgdGhl aXIgaWRlbnRpdHkgaXMgZXNzZW50aWFsbHkgZ29uZS4gV2hpbHN0IHRoZXJlIGhhcyBiZWVuIHNv bWUgaW50ZXJlc3RpbmcgcmVsYXRlZCB3b3JrIGZyb20gZ3JvdXBzIGxpa2UgTU9EUk5BIG9uIHNv bHV0aW9ucyB0byBjb21iYXQgdGhpcyBsaWtlICdBY2NvdW50IFBvcnRpbmcnLCB0aGV5IG9mdGVu IGFzc3VtZSB0aGUgb2xkIHByb3ZpZGVyIHJlbWFpbnMgb25saW5lIGFuZCB3aWxsaW5nIHRvIGZh Y2lsaXRhdGUgaW4gdGhlIGFjY291bnQgcG9ydGluZyBwcm9jZXNzIHNvIHRoYXQgdGhlIEVuZC1V c2VyIGNhbiBtaWdyYXRlIHRvIGEgbmV3IHByb3ZpZGVyLiBTSU9QIGFjdHVhbGx5IGVsZWN0ZWQg dG8gZG8gc29tZXRoaW5nIGRpZmZlcmVudCBoZXJlIGJ5IHVzaW5nIGNyeXB0b2dyYXBoeSwgaW5z dGVhZCBvZiB0aGUgRW5kLVVzZXIgaWRlbnRpZmllciBiZWluZyBzb21ldGhpbmcgbGlrZSBhIEdV SUQgYXNzZXJ0ZWQgd2l0aGluIHRoZSBkb21haW4gb2YgdGhlIHByb3ZpZGVyLCBTSU9QIGRlZmlu ZWQgdGhpcyBpbnN0ZWFkIGFzIGEgcHVibGljIGtleSBmaW5nZXJwcmludCBhc3NvY2lhdGVkIHRv IGEgcHJpdmF0ZSBrZXkgdGhhdCdzIGFzc3VtZWQgdG8gYmUgdW5kZXIgdGhlIGNvbnRyb2wgb2Yg dGhlIHVzZXIuIEluIGRvaW5nIHNvIHRoZSBpZGVudGl0eSBpdHNlbGYgYmVjb21lcyBwb3J0YWJs ZSBiZXR3ZWVuIHByb3ZpZGVycyBieSB0cmFuc2ZlcnJpbmcgdGhlIGFzc29jaWF0ZWQgcHJpdmF0 ZSBrZXkuIE5vdyB0aGlzIGFwcHJvYWNoIGRvZXMgaGF2ZSBkcmF3YmFja3MgYW5kIGFyZ3VhYmx5 IGVuY291cmFnZXMgd2hhdCBtYW55IHdvdWxkIHJlZmVyIHRvIGFzIGJhZCBjcnlwdG9ncmFwaGlj IHByYWN0aXNlIGJ5IG5vdCBhbGxvd2luZyBhbnkgd2F5IHRvIGRvIGtleSByb3RhdGlvbiwgaG93 ZXZlciB0aGUgaWRlYSB3YXMgdGhlcmUuDQoNCkhvdyBHTkFQIGNhbiBzb2x2ZSBmb3IgdGhpcz8g QnkgaGF2aW5nIGZsZXhpYmlsaXR5IGFyb3VuZCBob3cgdGhlIHJlc291cmNlIG93bmVyIC8gRW5k LVVzZXIgaXMgcmVmZXJyZWQgdG8gYnkgdGhlIEF1dGhvcml6YXRpb24gc2VydmVyIChlLmcgYWxs b3cgdGhlIGlkZW50aWZpZXIgdG8gYmUgc29tZXRoaW5nIGxpa2UgYSBwdWJsaWMga2V5IG9yIGEg cmVzb2x2YWJsZSBpZGVudGlmaWVyIHRvIHB1YmxpYyBrZXlzIHN1Y2ggYXMgYSBESUQpDQoNCkkg cGVyc29uYWxseSB0aGluayB0aGF0IEdOQVAgc2hvdWxkIGJlIGEgZmxleGlibGUgOmNhcnJpZXI6 IG9mIGlkZW50aWZpZXJzIGFuZCBvdGhlciBiaXRzIG9mIGlkZW50aXR5IGluZm9ybWF0aW9uLiBU aGlzIGlzIHRoZSBtYWluIHJlYXNvbiB3ZSB3ZW50IHdpdGggdGhlIFN1YmplY3QgSWRlbnRpZmll cnMgZHJhZnQgZnJvbSBTRUNFVkVOVDogaXTigJlzIHNldCB1cCB0byB0YWxrIGFib3V0IGEgdmFy aWV0eSBvZiBkaWZmZXJlbnQga2luZHMgb2YgaWRlbnRpZmllcnMsIGFsbCBvZiB0aGVtIGFzc2Vy dGVkIGluIHRoZSBjb250ZXh0IG9mIHRoZSBBUy4gSWYgdGhlcmXigJlzIGEgZGVmaW5pdGlvbiBm b3IgYSBESUQgVVJMIG9yIGEgSldLIGluIHRoZSBzdWJfaWRzIG9iamVjdCBzdHJ1Y3R1cmUsIEdO QVAgd291bGQgYmUgYWJsZSB0byBqdXN0IHVzZSBpdCBkaXJlY3RseSBhbG9uZ3NpZGUgZXZlcnkg b3RoZXIgZm9ybWF0LiBJIGhhdmVu4oCZdCBzZWVuIHRob3NlIHByb3Bvc2VkIHlldCwgYnV0IGl0 IHdvdWxkIGJlIGVhc3kgdG8gZG8gYW5kLCBpbiBteSBtaW5kLCB3b3VsZCBiZSBhIGJldHRlciBz b2x1dGlvbiB0aGFuIHRoZSBwb3J0YWJsZSBpZGVudGlmaWVycyBwcm9wb3NhbCB0aGF0IHdhcyBy ZWNlbnRseSBicm91Z2h0IHVwIGluIHRoZSBGQVBJIHdvcmtpbmcgZ3JvdXAgaW4gT0lERi4gKEEg c2lkZSBub3RlLCBidXQgdGhlIG1haW4gcHJvYmxlbSBJIGhhdmUgaGVyZSBpcyB0aGF0IGl04oCZ cyBwYXN0aW5nIHNlbWFudGljcyBhbmQgZm9ybWF0cyBvbnRvIGEgZmllbGQgd2hlcmUgbm9uZSBl eGlzdGVkIGJlZm9yZSwgYW5kIHRoYXTigJlzIHJpZmUgZm9yIHByb2JsZW1zLiBCZXR0ZXIgdG8g aGF2ZSBhIHN0cnVjdHVyZSB0aGF0IHRha2VzIHRoYXQgaW50byBhY2NvdW50IGZyb20gdGhlIHN0 YXJ0LCBpbiBteSB2aWV3LikNCg0KDQpTb2x2aW5nIHRoZSBOQVNDQVIgcHJvYmxlbSAtIE9uZSBv ZiB0aG9zZSBlbmR1cmluZyBwcm9ibGVtcyBpbiBpZGVudGl0eSBzeXN0ZW1zLCB3aGljaCBJIHRo aW5rIGlzIHJlYWxseSBhYm91dCB0aGUgdGhyZWUgd2F5IG5lZ290aWF0aW9uIGdvaW5nIG9uIGJl dHdlZW4gdGhlIFJQLCB0aGUgRW5kLVVzZXIgYW5kIHRoZSBQcm92aWRlci4gU0lPUCdzIHNvbHV0 aW9uIHB1c2hlZCBmb3IgbW9zdCBvZiB0aGUgcG93ZXIgaW4gdGhpcyBkZWNpc2lvbiBtYWtpbmcg cHJvY2VzcyB0byBsaWUgd2l0aCB0aGUgRW5kLVVzZXIsIGxldHRpbmcgdGhlbSBkZWNpZGUgd2hv IHRoZXkgd2FudCBhcyB0aGVpciBwcm92aWRlciByYXRoZXIgdGhhbiBSUCdzIHByb3ZpZGluZyBh biBlbnVtZXJhdGlvbiBvZiB3aG8gdGhleSBzdXBwb3J0IHZpYSBwcm92aWRlciBpY29ucyBvbiB0 aGVpciBsb2dpbiBwYWdlIGFuZCBFbmQtVXNlcnMgaGF2aW5nIHRvIHNlbGVjdCBmcm9tIHRob3Nl IG9wdGlvbnMuIEl0IGFjY29tcGxpc2hlZCB0aGlzIHZpYSB1c2luZyBhIGN1c3RvbSBVUkwgc2No ZW1lIG9mIGBvcGVuaWQ6Ly9gIHdoZXJlIHRoZSBFbmQtVXNlciB3b3VsZCByZWdpc3RlciB0aGVp ciBjaG9zZW4gcHJvdmlkZXIgYXMgYSBwcm90b2NvbCBoYW5kbGVyIGZvciB0aGUgYG9wZW5pZDov L2Agc2NoZW1lLiBIb3dldmVyLCBhZ2FpbiBhcyBhIHNvbHV0aW9uIGl0J3Mgbm90IHdpdGhvdXQg aXQncyBjaGFsbGVuZ2VzLCBub3RhYmx5OyBvbmx5IGEgc2luZ2xlIHJlZ2lzdHJhdGlvbiBhdCBh IHRpbWUgY2FuIGJlIHN1cHBvcnRlZCwgdGhlIGFjdHVhbCBpZGVudGl0eSBvZiB0aGUgcHJvdmlk ZXIgcmVtYWlucyBibGluZCB0byB0aGUgUlAgdW50aWwgYWZ0ZXIgdGhlIHJlcXVlc3QgaXMgc2Vu dCBhbmQgaXQgcmVxdWlyZXMgcmVnaXN0cmF0aW9uIG9yIHNvbWUgZm9ybSBvZiBkZWZhdWx0IGhh bmRsaW5nIChlLmcgd2hlbiB0aGVyZSBpcyBubyBwcm92aWRlciByZWdpc3RlcmVkKS4NCg0KSG93 IEdOQVAgY2FuIHNvbHZlIGZvciB0aGlzPyBJIGFjdHVhbGx5IGRvbid0IHRoaW5rIHRoaXMgaXMg Y29yZSB0byBHTkFQLCB0aGVyZSBtYXkgYmUgc29tZSBjb25zaWRlcmF0aW9ucyBhcm91bmQgZGlz Y292ZXJ5IHRoYXQgYXJlIHdvcnRoIHBheWluZyBhdHRlbnRpb24gdG8gYnV0IG5vdCBtdWNoIGlu IHRoZSBjb3JlIHByb3RvY29sIGRlc2lnbi4NCg0KDQpTSU9QIGRvZXNu4oCZdCByZWFsbHkgc29s dmUgdGhlIE5BU0NBUiBpc3N1ZSBzaW5jZSBTSU9QLCBieSBkZXNpZ24sIGJlY29tZXMgeWV0IG9u ZSBtb3JlIGxvZ2luIG9wdGlvbiBhbW9uZyBtYW55LiBJIHRoaW5rIEdOQVAgY2FuIGhlbHAgdGhp cyBieSBlbmFibGluZyB1c2VyLWRpcmVjdGVkIHByb3ZpZGVyIGRpc2NvdmVyeSB0byBraWNrIG9m ZiB0aGUgcHJvY2VzcywgYnV0IEkgYWdyZWUgdGhhdCB0aGUgY29yZSBwcm90b2NvbCBkb2VzbuKA mXQgcmVhbGx5IGhhdmUgbXVjaCB0byBzYXkgaGVyZSwgYW5kIHNob3VsZG7igJl0Lg0KDQpFeHBs b3JpbmcgZGlmZmVyZW50IGRlcGxveW1lbnQgbW9kZWxzIGZvciB0aGUgcHJvdmlkZXIgLSBUaGlz IGlzIHRoZSBtb3N0IGZyZXF1ZW50bHkgdGFsa2VkIGFib3V0IGFzcGVjdCBvZiBTSU9QIGFuZCBw ZXJoYXBzIHRoZSBtb3N0IGludGVyZXN0aW5nIHRvIEdOQVAuIEkgbGlrZSB0byB0aGluayBhYm91 dCB0aGUgc2NvcGUgb2YgdGhpcyBpc3N1ZSBhcyBkZXNpZ25pbmcgdG8gYWxsb3cgZm9yIGVpdGhl ciBhIHBhcnRpYWxseSBvciBmdWxseSBkaXN0cmlidXRlZC9kZWNlbnRyYWxpemVkIHByb3ZpZGVy LCByYXRoZXIgdGhhbiBhIGNlbnRyYWxpemVkIG9uZSAoZS5nIGFuIEhUVFAgYmFzZWQgQXV0aFog c2VydmVyKS4gQXMgeW91IG5vdGVkIHRoaXMgZG9lcyBjb21lIHdpdGggaXRzIGNoYWxsZW5nZXMg bWFueSBvZiB3aGljaCBhcmUgdGVjaG5pY2FsIGluIG5hdHVyZSwgaS5lIGhvdyB0byBhcHByb3By aWF0ZWx5IGFkZHJlc3MgYSBkZWNlbnRyYWxpemVkIHByb3ZpZGVyIGFuZCB3aGF0IHByb3RvY29s cyBhcmUgdXNlZCB0byBjb21tdW5pY2F0ZSB3aXRoIHRoZSBwcm92aWRlci4NCg0KSG93IEdOQVAg Y2FuIHNvbHZlIGZvciB0aGlzPyBJIHRoaW5rIHRoYXQncyB3aGF0IG11Y2ggb2YgdGhlIGRpc2N1 c3Npb24gb24gdGhpcyB0aHJlYWQgd2lsbCBiZSBhYm91dCBhbmQgd2hldGhlciB0aGVyZSBpcyBh IGh5YnJpZCBtb2RlbCB3aGVyZSBzb21lIHJlc3BvbnNpYmlsaXR5IGlzIHN0aWxsIGNlbnRyYWxs eSBhZG1pbmlzdGVyZWQgbGlrZSB0b2tlbiBpc3N1YW5jZSwgd2hpbGUgYWxsb3dpbmcgb3RoZXIg YXNwZWN0cyB0byBvY2N1ciBpbiBhIG1vcmUgZGlzdHJpYnV0ZWQgbWFubmVyLiBJZGVhbGx5IHRo b3VnaCBJJ2QgbGlrZSB0byBzZWUgY29uc2lkZXJhdGlvbiBmb3IgYSBjb21wbGV0ZWx5IGRpc3Ry aWJ1dGVkIG1vZGVsIHRvby4NCg0KSSBhZ3JlZSB0aGF0IHRoaXMgc2VlbXMgdG8gYmUgdGhlIG1v c3QgaW50ZXJlc3RpbmcgcGxhY2UgZm9yIG92ZXJsYXAuIEkgZG9u4oCZdCBhY3R1YWxseSB0aGlu ayB0aGUg4oCcaHlicmlk4oCdIGFwcHJvYWNoIGNlbnRyYWxpemVzIHRoaW5ncy4gSW5zdGVhZCwg eW91IGNhbiB0aGluayBvZiB0aGUgUlMgYXMgaGF2aW5nIGFuIGFzc29jaWF0ZWQgQVMsIGFuZCB0 aGF0IEFTIGFjY2VwdGluZyB1c2VyIGNvbnNlbnQgYW5kIGNsYWltcyBhdCBydW50aW1lIGZyb20g YSB2YXJpZXR5IG9mIHNvdXJjZXMgKHdhbGxldHMsIFZDcywgZXRjLikuIEluIHRoaXMgd2F5LCB3 ZSBhcmVu4oCZdCB0YWxraW5nIGFib3V0IGEgc2luZ2xlIEFTIGluIHRoZSB3b3JsZCBoYW5kbGlu ZyBhbGwgb2YgdGhlc2UgcmVxdWVzdHMsIHdl4oCZcmUgdGFsa2luZyBhYm91dCBhIGRpc3RyaWJ1 dGVkIG5ldHdvcmsgb2YgQVPigJlzIGFzc29jaWF0ZWQgd2l0aCBhbiBldmVuIG1vcmUgd2lkZWx5 IGRpc3RyaWJ1dGVkIHNldCBvZiBSU+KAmXMuIFNTSSBhbmQgaXRzIGFzc29jaWF0ZWQgdGVjaG5v bG9naWVzIHdvdWxkIGhlbHAgdGhlc2Ug4oCcbG9jYWzigJ0gQVPigJlzIGlzc3VlIGFjY2VzcyB0 b2tlbnMgd2l0aG91dCB0aGUgUk8gbmVlZGluZyB0byBoYXZlIGFuIGFjY291bnQsIG9yIGV2ZW4g bmVjZXNzYXJpbHkgZGlyZWN0bHkgaW50ZXJhY3Rpbmcgd2l0aCB0aGUgQVMuIFRoZXJl4oCZcyBj dXJyZW50bHkgYSB0ZWNobm9sb2d5IGdhcCB0aGVyZSwgYnV0IG15IHRob3VnaHRzIGFyZSB0aGF0 IHRoaXMgaXMgd2hlcmUgdGhlIGNoYW5nZXMgdG8gdGhlIGludGVyYWN0aW9uIG1vZGVzIHNlY3Rp b24gY2FuIHJlYWxseSBjb21lIHRvIHBsYXkuDQoNCkkgdGhpbmsgdGhlIG5vdGlvbiBvZiBhIG5v bi1IVFRQIEFTIGlzIGludGVyZXN0aW5nLCBidXQgSeKAmW0gbm90IHN1cmUgaWYgdGhhdOKAmXMg c29tZXRoaW5nIEdOQVAgb3VnaHQgdG8gYmUgc29sdmluZyBmb3IuIEkgdGhpbmsgdGhhdCB0aGVy ZeKAmXMgYSBkZWVwIHZhbHVlIGluIGJ1aWxkaW5nIG9uIHRvcCBvZiBIVFRQIGZvciB0aGUgY29y ZSBwcm90b2NvbCwgYW5kIG5vdCBhYnN0cmFjdGluZyBhd2F5IGNvbmNlcHRzIGZyb20gaXQuIE90 aGVyd2lzZSwgeW91IGVuZCB1cCByZS1pbnZlbnRpbmcgbGF5ZXJzLCBhbmQgeW91IGdldCBzb21l dGhpbmcgbGlrZSBTT0FQIGFsbCBvdmVyIGFnYWluLiA6KQ0KDQog4oCUIEp1c3Rpbg0KDQoNClRo YW5rcywNCltNYXR0ciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgd2Vic2l0ZV08aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS91cmw/cT1odHRw czovL21hdHRyLmdsb2JhbC8mc291cmNlPWdtYWlsLWltYXAmdXN0PTE2MTQzNzk4MjgwMDAwMDAm dXNnPUFPdlZhdzJ3OUFMLVRMMlFsSE82Und4cVdReVo+DQpUb2JpYXMgTG9va2VyDQpNYXR0cg0K KzY0ICgwKSAyNyAzNzggMDQ2MQ0KdG9iaWFzLmxvb2tlckBtYXR0ci5nbG9iYWw8bWFpbHRvOnRv Ymlhcy5sb29rZXJAbWF0dHIuZ2xvYmFsPg0KW01hdHRyIHdlYnNpdGVdPGh0dHBzOi8vd3d3Lmdv b2dsZS5jb20vdXJsP3E9aHR0cHM6Ly9tYXR0ci5nbG9iYWwvJnNvdXJjZT1nbWFpbC1pbWFwJnVz dD0xNjE0Mzc5ODI4MDAwMDAwJnVzZz1BT3ZWYXcydzlBTC1UTDJRbEhPNlJ3eHFXUXlaPiAgICAg W01hdHRyIG9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBMaW5rZWRJbl0gPGh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vdXJsP3E9aHR0cHM6 Ly93d3cubGlua2VkaW4uY29tL2NvbXBhbnkvbWF0dHJnbG9iYWwmc291cmNlPWdtYWlsLWltYXAm dXN0PTE2MTQzNzk4MjgwMDAwMDAmdXNnPUFPdlZhdzNsTU1xOE5CYzJTUXlkUE4yTDQ1NkE+ICAg ICAgIFtNYXR0ciBvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgVHdpdHRlcl0gPGh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vdXJsP3E9aHR0 cHM6Ly90d2l0dGVyLmNvbS9tYXR0cmdsb2JhbCZzb3VyY2U9Z21haWwtaW1hcCZ1c3Q9MTYxNDM3 OTgyODAwMDAwMCZ1c2c9QU92VmF3MHplU0w5c25fYWstVU9CTXEweVBxdj4gICAgIFtNYXR0ciBv biAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgR2l0aHViXSA8aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS91cmw/cT1odHRwczovL2dpdGh1Yi5j b20vbWF0dHJnbG9iYWwmc291cmNlPWdtYWlsLWltYXAmdXN0PTE2MTQzNzk4MjgwMDAwMDAmdXNn PUFPdlZhdzJELUVYS2lGVndpT1h5bm9DbllPVlE+DQoNClRoaXMgY29tbXVuaWNhdGlvbiwgaW5j bHVkaW5nIGFueSBhdHRhY2htZW50cywgaXMgY29uZmlkZW50aWFsLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ugc2hvdWxkIG5vdCByZWFkIGl0IC0gcGxlYXNlIGNv bnRhY3QgbWUgaW1tZWRpYXRlbHksIGRlc3Ryb3kgaXQsIGFuZCBkbyBub3QgY29weSBvciB1c2Ug YW55IHBhcnQgb2YgdGhpcyBjb21tdW5pY2F0aW9uIG9yIGRpc2Nsb3NlIGFueXRoaW5nIGFib3V0 IGl0LiBUaGFuayB5b3UuIFBsZWFzZSBub3RlIHRoYXQgdGhpcyBjb21tdW5pY2F0aW9uIGRvZXMg bm90IGRlc2lnbmF0ZSBhbiBpbmZvcm1hdGlvbiBzeXN0ZW0gZm9yIHRoZSBwdXJwb3NlcyBvZiB0 aGUgRWxlY3Ryb25pYyBUcmFuc2FjdGlvbnMgQWN0IDIwMDIuDQoNCg0KT24gVGh1LCBGZWIgMTgs IDIwMjEgYXQgOToxOSBQTSBGYWJpZW4gSW1iYXVsdCA8ZmFiaWVuLmltYmF1bHRAZ21haWwuY29t PG1haWx0bzpmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb20+PiB3cm90ZToNCkhpIEp1c3RpbiwNCg0K SSBhZ3JlZSB0aGF0IGRlZmluaW5nIEFTIHJvbGUgcHJpbWFyaWx5IGFzIGEgdG9rZW4gaXNzdWVy IGlzIGEgZnJ1aXRmdWwgaWRlYS4gU29sdmluZyB0aGlzIHByb2JsZW0gd2VsbCB3b3VsZCBhbHNv IHJlc3BvbmQgdG8gdGhlIGNoYWxsZW5nZXMgZGlzY3Vzc2VkIHByZXZpb3VzbHkgb24gdGhlIGxp c3QuDQoNCkNoZWVycw0KRmFiaWVuDQoNCg0KTGUgbWVyLiAxNyBmw6l2ci4gMjAyMSDDoCAyMzoy NywgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+ PiBhIMOpY3JpdCA6DQpUaGUgbGFzdCBpbnRlcmltIGNhbGwgaGFkIGEgbG90IG9mIGRpc2N1c3Np b24gb24gU1NJIHRlY2hub2xvZ2llcyBzdWNoIGFzIGRpZ2l0YWwgd2FsbGV0cywgYW5kIGhvdyB0 aG9zZSBmaXQgd2l0aCBHTkFQLiBJIHRoaW5rIGl04oCZcyB3b3J0aCBjb250aW51aW5nIHRoYXQg Y29udmVyc2F0aW9uIGhlcmUgb24gdGhlIGxpc3QuIFRoZXJlIGFyZSBhIGZldyBpc3N1ZXMgaW4g dGhlIHRyYWNrZXIgdGhhdCBnaXZlIHNvbWUgYmFja2dyb3VuZCwgdG9vOg0KDQpodHRwczovL2dp dGh1Yi5jb20vaWV0Zi13Zy1nbmFwL2duYXAtY29yZS1wcm90b2NvbC9pc3N1ZXMvMTc1PGh0dHBz Oi8vd3d3Lmdvb2dsZS5jb20vdXJsP3E9aHR0cHM6Ly9naXRodWIuY29tL2lldGYtd2ctZ25hcC9n bmFwLWNvcmUtcHJvdG9jb2wvaXNzdWVzLzE3NSZzb3VyY2U9Z21haWwtaW1hcCZ1c3Q9MTYxNDM3 OTgyODAwMDAwMCZ1c2c9QU92VmF3MXFuZDJGNzl6bVFrX0xHdGF5c0tlUD4NCg0KVGhlcmXigJlz IGJlZW4gYSBsb3Qgb2YgaW50ZXJlc3Rpbmcgd29yayByZWNlbnRseSBpbiB0aGUgT3BlbklEIEZv dW5kYXRpb24gYXJvdW5kIHVzaW5nIHRoZSBTZWxmLWlzc3VlZCBPUCAoU0lPUCkgZnVuY3Rpb25h bGl0eSB0byBib290c3RyYXAgYW4gU1NJIHN0eWxlIGxvZ2luLiBUaGlzIG1ha2VzIGV4dGVuc2l2 ZSB1c2Ugb2YgdGhlIGltcGxpY2l0IGZsb3cgYW5kIGZyb250IGNoYW5uZWwgbWVzc2FnaW5nLCBi dXQgbWluaW1pemF0aW9uIG9mIHRoZSBmcm9udCBjaGFubmVsIGZvciBtZXNzYWdlIHBhc3Npbmcg aXMgYSBrZXkgZGVzaWduIHRlbmV0IG9mIEdOQVAgKHNvIG11Y2ggc28gdGhhdCBpdOKAmXMgaW5j bHVkZWQgaW4gb3VyIGNoYXJ0ZXIpLiBJbnN0ZWFkLCBHTkFQIGhhcyBiZWVuIGJ1aWx0IGFyb3Vu ZCBhbiBpZGVhIHRoYXQgZXZlcnl0aGluZyBzdGFydHMgdGhlIHNhbWUgd2F5OiB3aXRoIGFuIEhU VFAgcmVxdWVzdCB0byB0aGUgQVMuDQoNClRoZSBpZGVhIG9mIGFuIG9uLWRldmljZSBBUyBoYXMg YmVlbiBicm91Z2h0IHVwIGEgbG90LCBhbmQgd2UgbmVlZCB0byBjb25zaWRlciBpZiBhbmQgaG93 IHdlIHdhbnQgdG8gZGVhbCB3aXRoIHRoZXNlIGtpbmRzIG9mIHVzZSBjYXNlcy4gVGhlIG1vc3Qg b2J2aW91cyB3YXkgdG8gYWRkcmVzcyB0aGVzZSB3b3VsZCBiZSB0byBkbyBzb21lIGtpbmQgb2Yg Y2xldmVyIG9mZi1IVFRQIGhhY2sgbGlrZSBTSU9QLCBidXQga2VlcCBpbiBtaW5kIHRoYXQgZXZl biBTSU9QIGdlbmVyYWxseSBzdGFydHMgb2ZmIHdpdGggYW4gSFRUUC1iYXNlZCBkaXNjb3Zlcnkg Y2FsbCBieSB0aGUgUlAgdG8gbWFrZSB0aGluZ3Mgd29yay4NCg0KTXkgcGVyc29uYWwgc3RhbmNl IGlzIHRoYXQgdG8gZG8gdGhpcywgd2UgbmVlZCB0byByZS1ldmFsdWF0ZSBvdXIgYXNzdW1wdGlv bnMgYWJvdXQgZXhhY3RseSB3aGF0IGFuIEFTIGRvZXMgYW5kIHdoYXQgaXQgbmVlZHMgdG8gZG8g dGhvc2UgdGhpbmdzLiBJbiBPQXV0aCAyLCBpdOKAmXMgYXNzdW1lZCB0aGF0IHRoZSBBUyBpcyB0 aGUgZGV2aWNlIHRoYXTigJlzIGF1dGhlbnRpY2F0aW5nIHRoZSB1c2VyLCBjb2xsZWN0aW5nIGNv bnNlbnQsIG1hbmFnaW5nIHRoZSBjbGllbnTigJlzIHJlZ2lzdHJhdGlvbiwgYW5kIGNyZWF0aW5n IGFuIGFjY2VzcyB0b2tlbiBiYXNlZCBvbiB3aGF0ZXZlciBzZXQgb2YgcmlnaHRzIHRoYXQgYXJl IGFzc29jaWF0ZWQgd2l0aCBhbGwgb2YgdGhvc2UgdGhpbmdzLiBJbiBVTUEsIHRoaXMgaXMgdHVy bmVkIGFyb3VuZCBhIGJpdCBieSBsZXR0aW5nIHRoZSBSTyBwcmVzZW50IGEgYnVuY2ggb2YgbmVi dWxvdXMg4oCcY2xhaW1z4oCdIGludGVyYWN0aXZlbHksIGJ1dCBzdGlsbCBhdCB0aGUgQVMuDQoN CldpdGggYm90aCBvZiB0aGVzZSwgYSBrZXkgYXNwZWN0IHJlbWFpbnM6IHRoZSBBUyBuZWVkcyB0 byBnYXRoZXIgbmVjZXNzYXJ5IGluZm9ybWF0aW9uLCBhbmQgaXNzdWUgdGhlIGFjY2VzcyB0b2tl biAob3IgaWRlbnRpZmllcnMvYXNzZXJ0aW9ucykuIEJlY2F1c2Ugb2YgaG93IHRoZSBwcm90b2Nv bCB3b3JrcywgdGhlIGNsaWVudCBzb2Z0d2FyZSBub3cgaGFzIGEgYmV0dGVyIG9wcG9ydHVuaXR5 IHRvIHByZXNlbnQgaW5mb3JtYXRpb24gdG8gdGhlIEFTLCBlaXRoZXIgZGlyZWN0bHkgaW4gdGhl IHJlcXVlc3Qgb3IgYnkgaW50cm9kdWNpbmcgdGhlIEFTIHRvIGFub3RoZXIgc29mdHdhcmUgY29t cG9uZW50IGR1cmluZyB0aGUg4oCcaW50ZXJhY3Rpb27igJ0gcGhhc2UuIFNvLCB3aGF0IGlmIHdl IHRoaW5rIG9mIHRoZSBBUyBwcmltYXJpbHkgYXMgYSDigJx0b2tlbiBpc3N1ZXLigJ0/DQoNCkZv ciBleGFtcGxlLCBpZiB0aGUgY2xpZW50IGNhbiBwcmVzZW50IGEgdmVyaWZpYWJsZSBjcmVkZW50 aWFsIChWQykgdGhhdCByZXByZXNlbnRzIHRoZSBlbmQgdXNlciwgdGhlIEFTIGNhbiB2YWxpZGF0 ZSB0aGF0IFZDIGFuZCBtYWtlIGFuIGFjY2VzcyB0b2tlbiBvbiBiZWhhbGYgb2YgdGhhdCB1c2Vy LCB3aXRob3V0IGhhdmluZyB0aGUgdXNlciBsb2cgaW4gb3IgaW50ZXJhY3Qgd2l0aCB0aGUgQVMg YXQgYWxsLiBUaGlzIFZDIGNhbiBjb250YWluIHdoYXRldmVyIGFjY2VzcyByaWdodHMgdGhlIHRv a2VuIG5lZWRzIHRvIHJlcHJlc2VudCwgYW5kIHRoZSBBUyBjYW4gdHJhbnNsYXRlIHRoYXQgaW50 byBhbiBhcnRpZmFjdCB0aGF0IHRoZSBkb3duc3RyZWFtIFJT4oCZcyBjYW4gaW50ZXJwcmV0LCB3 aXRob3V0IGhhdmluZyB0byBzZWUgdGhlIG9yaWdpbmFsIFZDIG9yIHRoZSB1c2VyIGF0IGFsbC4g VGhlIEFTIGlzIHN0aWxsIEhUVFAgYmFzZWQsIGJ1dCBhbGwgdGhlIGVzc2VudGlhbCBzZWN1cml0 eSBhbmQgcmlnaHRzIGVsZW1lbnRzIGFyZSBwcm92aWRlZCBieSB0aGUgd2FsbGV0LiBJbiB0aGlz IHdheSwgd2UgY2FuIGV4cGFuZCBvbiB0aGUgcHJpdmFjeS1wcmVzZXJ2aW5nIGFzcGVjdHMgb2Yg T0F1dGggYW5kIGJyaWRnZSB0aGUgd29ybGRzIG9mIFNTSSBhbmQgd2ViIEFQSXMgd2l0aG91dCB2 aW9sYXRpbmcgdGhlIGJhc2ljIG5hdHVyZSBvZiBlaXRoZXIuDQoNCkNvbWluZyBmcm9tIHRoZSBP QXV0aCB3b3JsZCwgaXQgZmVlbHMgd2VpcmQgdG8gaXNzdWUgdG9rZW5zIGxpa2UgdGhpcywgYnV0 IHRoZXJl4oCZcyBwcmVjZWRlbnQgZm9yIHRoaXMga2luZCBvZiB0aGluZy4gVG9kYXksIGEgdGhl cmUgYXJlIGEgbnVtYmVyIG9mIHNlcnZpY2UtYmFzZWQgT0F1dGggQVMncyB0aGF0IGFyZSB0b2xk IHdoYXQgY2xhaW1zIG5lZWQgdG8gZ2V0IHB1dCBpbnRvIHRoZSBhY2Nlc3MgdG9rZW4gYnkgc29t ZSB0cnVzdGVkIGNvbXBvbmVudC4gQWxsIG9mIHRoaXMgaGFwcGVucyBvdXRzaWRlIHRoZSBPQXV0 aCBwcm90b2NvbC4gSW4gR05BUCwgSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBhY2NvdW50IGZv ciB0aGlzIGtpbmQgb2YgdGhpbmcgaW4gaG93IHdlIGRlZmluZSB0aGUgcHJvdG9jb2wuIFRoYXQg aXNu4oCZdCB0byBzYXkgYWxsIG9mIHRoZXNlIHBpZWNlcyBuZWVkIHRvIGJlIGRlZmluZWQgaW4g dGhlIGNvcmUsIGJ1dCB0aGUgYmFzZSBwcm90b2NvbCBvdWdodCB0byBiZSBhYmxlIHRvIGhhbmRs ZSBiZWluZyBleHRlbmRlZCBpbiB0aGlzIGRpcmVjdGlvbiBhcyBuZWVkZWQuDQoNCknigJltIHJl YWxseSBpbnRlcmVzdGVkIHRvIGhlYXIgb3RoZXIgcGVvcGxl4oCZcyB0aG91Z2h0cyBvbiBob3cg dGhpcyBjb3VsZCBjb21lIHRvZ2V0aGVyLg0KDQog4oCUIEp1c3Rpbg0KLS0NClRYQXV0aCBtYWls aW5nIGxpc3QNClRYQXV0aEBpZXRmLm9yZzxtYWlsdG86VFhBdXRoQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8aHR0cHM6Ly93d3cuZ29vZ2xl LmNvbS91cmw/cT1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCZz b3VyY2U9Z21haWwtaW1hcCZ1c3Q9MTYxNDM3OTgyODAwMDAwMCZ1c2c9QU92VmF3M2F2c1VHUTQ4 Zm8xT1VRVjB2eXlLZD4NCi0tDQpUWEF1dGggbWFpbGluZyBsaXN0DQpUWEF1dGhAaWV0Zi5vcmc8 bWFpbHRvOlRYQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHhhdXRoPGh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vdXJsP3E9aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgmc291cmNlPWdtYWlsLWltYXAmdXN0PTE2MTQz Nzk4MjgwMDAwMDAmdXNnPUFPdlZhdzNhdnNVR1E0OGZvMU9VUVYwdnl5S2Q+DQoNCg0KVGhpcyBj b21tdW5pY2F0aW9uLCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzLCBpcyBjb25maWRlbnRpYWwu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBzaG91bGQgbm90IHJl YWQgaXQgLSBwbGVhc2UgY29udGFjdCBtZSBpbW1lZGlhdGVseSwgZGVzdHJveSBpdCwgYW5kIGRv IG5vdCBjb3B5IG9yIHVzZSBhbnkgcGFydCBvZiB0aGlzIGNvbW11bmljYXRpb24gb3IgZGlzY2xv c2UgYW55dGhpbmcgYWJvdXQgaXQuIFRoYW5rIHlvdS4gUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGNv bW11bmljYXRpb24gZG9lcyBub3QgZGVzaWduYXRlIGFuIGluZm9ybWF0aW9uIHN5c3RlbSBmb3Ig dGhlIHB1cnBvc2VzIG9mIHRoZSBFbGVjdHJvbmljIFRyYW5zYWN0aW9ucyBBY3QgMjAwMi4NCg0K LS0NClRYQXV0aCBtYWlsaW5nIGxpc3QNClRYQXV0aEBpZXRmLm9yZzxtYWlsdG86VFhBdXRoQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8aHR0 cHM6Ly93d3cuZ29vZ2xlLmNvbS91cmw/cT1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3R4YXV0aCZzb3VyY2U9Z21haWwtaW1hcCZ1c3Q9MTYxNDM3OTgyODAwMDAwMCZ1c2c9 QU92VmF3M2F2c1VHUTQ4Zm8xT1VRVjB2eXlLZD4NCi0tDQpUWEF1dGggbWFpbGluZyBsaXN0DQpU WEF1dGhAaWV0Zi5vcmc8bWFpbHRvOlRYQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmdvb2ds ZS5jb20vdXJsP3E9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgm c291cmNlPWdtYWlsLWltYXAmdXN0PTE2MTQzNzk4MjgwMDAwMDAmdXNnPUFPdlZhdzNhdnNVR1E0 OGZvMU9VUVYwdnl5S2QNCg0KDQoNCg0K --_000_FR2P281MB013815C2EA1CC7FEBAB88FD08D9F9FR2P281MB0138DEUP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNv bG9yOiByZ2IoMCwgMCwgMCk7Ij4NCkludGVncmF0aW5nIEdOQVAgYW5kIFNTSSByZXF1aXJlcyBh IGxvdCBvZiBmdW5kYW1lbnRhbHM6PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xv cjogcmdiKDAsIDAsIDApOyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjx1bD4NCjxsaT48c3Bhbj5BUyBoYWQgdGhlaXIgZXNz ZW5jZSBpbiB0aGUgZmFjdCB0aGF0IGh1bWFuIGhlbGQgZGV2aWNlcyB3ZXJlIG5vdCBhYmxlIHRv IHByb2R1Y2UgYXV0aG9yaXphdGlvbiBzaGFyYWJsZSB0byBjbGllbnQgYW5kIFJTPC9zcGFuPjwv bGk+PGxpPjxzcGFuPklmIHRoZSBodW1hbiBoZWxkIGRldmljZSBjYW4gZG8gdGhlIHdvcmssIGl0 IGlzIG5hdHVyYWwgdGhlIG1vbWVudHVtIHdpbGwgc2hpZnQgaW4gdGhhdCBkaXJlY3Rpb24uIFRo aXMgaXMgd2hhdCBpcyBoYXBwZW5pbmcgd2l0aCBTU0kuPC9zcGFuPjwvbGk+PGxpPjxzcGFuPlNo YXJpbmcgYWxsIHZpZXdzIG9mIEFkcmlhbiBtZW50aW9uIGluIHRoaXMgdGhyZWFkKG5vIG5lZWQg dG8gcmVwZWF0KS4mbmJzcDs8L3NwYW4+PC9saT48bGk+PHNwYW4+QnV0IHJlcGVhdGluZyB0aGUg a2V5d29yZDogWlRBLiBLZWVwaW5nIGN1c3RvZGlhbiwgc2VydmVyIGNlbnRlcmVkIGFyY2hpdGVj dHVyZXMgdW5kZXIgY29udHJvbCBpcyBnZXR0aW5nIHRvdWdoZXIgYXMgdGltZSBnb2VzIGJ5Ljxi cj4NCjwvc3Bhbj48L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXYgaWQ9ImFwcGVuZG9uc2VuZCI+PC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5z LXNlcmlmOyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQpJbiBHTkFQIGluaXRp YWwgZGlzY3Vzc2lvbiwgd2Ugd2Fsa2VkIHRocm91Z2ggYSBsb3Qgb2YgYWJzdHJhY3QgZGlhZ3Jh bSwgdGhhdCBjb3VsZCBoYXZlIGFsbG93ZWQgcHJvZHVjdGlvbiBvZiBhdXRob3JpemF0aW9uIGFu ZCBhdXRoZW50aWNhdGlvbiBtYXRlcmlhbCAodG9rZW4pIGJ5IGh1bWFuIGhlbGQgZGV2aWNlcy4g VGhlIGludGVudGlvbiB3YXMgaW5zcGlyZWQgZnJvbSBTU0kgZGlzY3Vzc2lvbnMuJm5ic3A7PC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5z LXNlcmlmOyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQo8YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZToxMnB0OyBjb2xvcjpyZ2IoMCwwLDApIj4NCklGPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250 LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQombmJzcDsgSnVzdGluIGlzIGFza2luZyB0 byByZWNvbnNpZGVyIGFuIGludGVncmF0aW9uIG9mIFNTSSw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTox MnB0OyBjb2xvcjpyZ2IoMCwwLDApIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOjEycHQ7 IGNvbG9yOnJnYigwLDAsMCkiPg0KVEhFTjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOjEycHQ7IGNvbG9y OnJnYigwLDAsMCkiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEy cHQ7Ij53ZSBuZWVkIHRvIHJldmlldyB0aGUgYWJzdHJhY3QgcHJvdG9jb2wgZmxvd3M6PC9zcGFu Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2 ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOjEycHQ7IGNvbG9yOnJnYigwLDAsMCkiPg0KPHVs Pg0KPGxpPjxzcGFuPnJvbGVzPC9zcGFuPjwvbGk+PGxpPjxzcGFuPmVudGl0aWVzPC9zcGFuPjwv bGk+PGxpPjxzcGFuPnJlbGF0aW9uc2hpcHM8L3NwYW4+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyBm b250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQpXZSB3aWxsIGhhdmUgdG8gc3RhcnQg YnkgdGFraW5nIHRoZSBodHRwIHByb3RvY29sIGNvbnN0cmFpbnQgb3V0IG9mIHRoZSBjaGFydGVy LjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Es c2Fucy1zZXJpZjsgZm9udC1zaXplOjEycHQ7IGNvbG9yOnJnYigwLDAsMCkiPg0KPGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5z LXNlcmlmOyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQpCVFc8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZToxMnB0OyBjb2xvcjpyZ2IoMCwwLDApIj4NCjx1bD4NCjxsaT5JIGFncmVlIHdp dGggSnVzdGluOiAmcXVvdDtUaGUgUlMgZGVjaWRlcyBvbiBob3cgdG8gY29uc3VtZSBhIHByZXNl bnRlZCB0b2tlbi4mcXVvdDs8L2xpPjxsaT5JIGFncmVlIHdpdGggRGVuaXM6ICZxdW90O0FTIHBs YXlzIG5vIHJvbGUgYW5kIHNoYWxsIGhhdmUgbm8gaW5mbHVlbmNlIG9uIHRoZSBSUyBkZWNpc2lv biBvbiBob3cgdG8gY29uc3VtZSBhIHRva2VuLiZxdW90OzwvbGk+PC91bD4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsg Zm9udC1zaXplOjEycHQ7IGNvbG9yOnJnYigwLDAsMCkiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250 LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQpUSEVOPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6 MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQpXZSBtdXN0IHN0YXJ0IGJ5IHNoYXJwaW5nIHRoZSBt ZWFuaW5nIG9mIGFuIEFTIChpbiB0aGUgY29udGV4dCBvZiBHTkFQKS4gRGlzY3Vzc2lvbiBtaWdo dCBsZWFkIHRvIGEgcmV0aXJlbWVudCBvZiB0aGlzIHRlcm0uIEFzIG1vcnRhbHMgbWlnaHQgaGF2 ZSBhIGhhcmQgdGltZSBjb25zaWRlcmluZyBhIHVzZXIgaGVsZCBkZXZpY2UgYSBzZXJ2ZXIuPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5z LXNlcmlmOyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQo8YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZToxMnB0OyBjb2xvcjpyZ2IoMCwwLDApIj4NCkVORCBJRjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsg Zm9udC1zaXplOjEycHQ7IGNvbG9yOnJnYigwLDAsMCkiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250 LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZToxMnB0OyBjb2xvcjpyZ2IoMCwwLDApIj4NCk5ldmVydGhlbGVzcywgdGhlIHRyYW5zaXRpb24g ZnJvbSAoaHR0cCktQVMgYmFzZWQgdG9rZW4gcHJvZHVjdGlvbiB0byB1c2VyIGRldmljZS1iYXNl ZCB0b2tlbiBwcm9kdWN0aW9uIHdpbGwgbmVlZCBzb21lIDEwKyB5ZWFycyB0byBjb21wbGV0ZS4g U3RpbGwgYSBsb3Qgb2YgY2hhbGxlbmdlcyBhcm91bmQgaG93IHRvIHByb3RlY3Qga2V5cyBoZWxk IG9uIHVzZXIgZGV2aWNlcyBhZ2FpbnN0IGRhbWFnZSwgbG9zcyBvZiBkZXZpY2UsIG1hbHdhcmUs DQogcmFuc29td2FyZSwgc29jaWFsIGVuZ2luZWVyZWQgYXR0YWNrLjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1z aXplOjEycHQ7IGNvbG9yOnJnYigwLDAsMCkiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6 MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQpDYW4gR05BUCBiZSB0aGUgbWFpbiB2ZWhpY2xlIGZv ciB0aGlzIHRyYW5zaXRpb24/IE1heWJlLiBEZXNwaXRlIHRoZSAodG9vKSBzdHJvbmcgcmVsaWFu Y2Ugb24gdGhlIE9BdXRoIGxlZ2FjeSAoZXZlbiBpZiBHTkFQIGRvZXMgbm90IHByb21pc2UgYmFj a3dhcmQgY29tcGF0aWJpbGl0eSB0byBPQXV0aCksIGFuDQo8Yj5lbWJlZGRlZDwvYj4gaW50ZXJh Y3Rpb24gdGhhdCBhbGxvd3MgdGhlIGNsaWVudCB0byBjYXJyeSB0aGUgdXNlciBkZXZpY2UgcHJv ZHVjZWQgdG9rZW4gdG8gdGhlIHJlc291cmNlIHNlcnZlciBtaWdodCBwYXZlIHdheSBmb3IgdGhp cyB0cmFuc2l0aW9uLiBJIGNhbXBhaWduZWQgZm9yIGNvbnNpZGVyYXRpb24gb2YgYW4NCjxiPmVt YmVkZGVkIGludGVyYWN0aW9uPC9iPiBpbiB0aGUgaW5pdGlhbCBjb252ZXJzYXRpb24uIEkgYW0g bm90IHN1cmUgdGhpcyB3YXMgdGFrZW4gaW50byBhY2NvdW50LiBTdGlsbCBtdXN0IGZpbmQgdGlt ZSB0byByZXZpZXcgdGhlIGN1cnJlbnQgZHJhZnQuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTJwdDsg Y29sb3I6cmdiKDAsMCwwKSI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMnB0OyBjb2xv cjpyZ2IoMCwwLDApIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOjEycHQ7IGNvbG9yOnJn YigwLDAsMCkiPg0KL0ZyYW5jaXM8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMnB0OyBjb2xvcjpyZ2Io MCwwLDApIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxB cmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOjEycHQ7IGNvbG9yOnJnYigwLDAs MCkiPg0KPGJyPg0KPC9kaXY+DQo8aHIgdGFiaW5kZXg9Ii0xIiBzdHlsZT0iZGlzcGxheTppbmxp bmUtYmxvY2s7IHdpZHRoOjk4JSI+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+ PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgY29sb3I9IiMwMDAwMDAiIHN0eWxlPSJm b250LXNpemU6MTFwdCI+PGI+RnJvbTo8L2I+IFRYQXV0aCAmbHQ7dHhhdXRoLWJvdW5jZXNAaWV0 Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBEZW5pcyAmbHQ7ZGVuaXMuaWV0ZkBmcmVlLmZyJmd0Ozxi cj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAyMywgMjAyMSAxMjo1MSBQTTxicj4N CjxiPlRvOjwvYj4gSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0OzsgdHhhdXRo IGduYXAgJmx0O3R4YXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtH TkFQXSBJbnRlZ3JhdGluZyBhIEdOQVAgQVMgd2l0aCB3YWxsZXRzIGFuZCBTU0k8L2ZvbnQ+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0ieF9tb3otY2l0ZS1w cmVmaXgiPkhpJm5ic3A7IEp1c3Rpbiw8L2Rpdj4NCjxkaXYgY2xhc3M9InhfbW96LWNpdGUtcHJl Zml4Ij48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfbW96LWNpdGUtcHJlZml4Ij5TZWUgbXkg Y29tbWVudHMgYmV0d2VlbiB0aGUgbGluZXMuPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij5BbiBpbXBvcnRhbnQgYXNwZWN0IGluIHRoZSBkaXNjdXNzaW9uIGhlcmUsIHRoYXQgSSBhZ3Jl ZSB3aXRoLCBpcyB0aGF0IHRoZSBSUyBuZWVkcyB0byBiZSBhYmxlIHRvIGRlY2lkZQ0KPHU+PGk+ d2hpY2ggQVMgaXQgdGFsa3MgdG88L2k+PC91Pi4gPC9ibG9ja3F1b3RlPg0KPHA+PGZvbnQgY29s b3I9IiMwMDAwZmYiPiZuYnNwO1doaWxlIEkgd291bGQgYWdyZWUgd2l0aCBzdWNoIGEgc2VudGVu Y2UgaW4gdGhlIE9BdXRoIFdHLCBJIGRvbid0IGJlbGlldmUgdGhhdCB0aGlzIHNlbnRlbmNlIGlz IGFwcGxpY2FibGUgaW4gZ2VuZXJhbCBpbiB0aGUgY29udGV4dCBvZiBHTkFQLjxicj4NCkEgUlMg ZG9lcyBub3QgbmVlZCB0byAmcXVvdDt0YWxrIHRvJnF1b3Q7IGFueSBBUy4gQSBSUyBkZWNpZGVz IHdoaWNoIEFTKHMpIGl0IHRydXN0cyB0byBpc3N1ZSBhY2Nlc3MgdG9rZW5zDQo8Yj50aGF0IGNv bnRhaW5zIHNvbWUgc2V0IG9mIHByaXZpbGVnZXM8L2I+LjwvZm9udD48YnI+DQo8L3A+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj5CdXQgaW5oZXJlbnQgaW4gdGhhdCBpcyB0aGF0IGl04oCZcyBu b3QgdGhlIHVzZXLigJlzIGRlY2lzaW9uLCBvciB0aGUgQVPigJlzIGRlY2lzaW9uLCBpdOKAmXMg dGhlIFJT4oCZcyBkZWNpc2lvbiB3aG8gaXQgd2lsbCB0cnVzdCB0byBnZXQgdG9rZW5zIGZyb20u DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8cD48Zm9udCBjb2xvcj0iIzAwMDBmZiI+QSBSUyBkb2Vz IG5vdCBuZWNlc3NhcmlseSBuZWVkIHRvIHRydXN0IGFsbCB0aGUgYWNjZXNzIHRva2VucyBpc3N1 ZWQgYnkgYSBnaXZlbiBBUywgYnV0IG9ubHkgYWNjZXNzIHRva2VucyBmcm9tIGEgZ2l2ZW4gQVMg dGhhdCBjb250YWluDQo8YnI+DQo8Yj5hIGdpdmVuIHNldCBvZiBwcml2aWxlZ2VzPC9iPi4gPC9m b250Pjxicj4NCjwvcD4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPkFuZCBubyBtYXR0ZXIgd2hh dCBvdXIgcGhpbG9zb3BoeSwgYXQgdGhlIGVuZCBvZiB0aGUgZGF5IHRoZSBSUyB3aWxsIGFsd2F5 cyBoYXZlIHRoZSBjaG9pY2Ugb2Ygd2hldGhlciB0byB0cnVzdCBhbiBpbmJvdW5kIHJlcXVlc3Qu PC9ibG9ja3F1b3RlPg0KPHA+PGZvbnQgY29sb3I9IiMwMDAwZmYiPk5vdCBleGFjdGx5OiB0aGUg UlMgd2lsbCBhcHBseSB0aGUgcnVsZXMgZ2l2ZW4gYnkgdGhlIFJPLjwvZm9udD48L3A+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgY2xhc3M9IiI+V2hpY2ggaXMgd2h5LCB0byBtZSwg dGhpcyByZWFsbHkgYnJpbmdzIHVzIHRvIHRoZSBxdWVzdGlvbiBvZiB3aGF0IGFuIEFTIHByb3Zp ZGVzLiBUaGUgQVMgZ2l2ZXMgdGhlIFJTIGEgdG9rZW4gdGhhdCB0aGUgUlMgZGVjaWRlcyB0byB0 cnVzdCwNCjxicj4NCmFuZCB0aGF0IHRoZSBSUyBjYW4gdW5kZXJzdGFuZCAoZWl0aGVyIGRpcmVj dGx5IHdpdGggc29tZXRoaW5nIGxpa2UgSldUIG9yIGluZGlyZWN0bHkgd2l0aCBzb21ldGhpbmcg bGlrZSBpbnRyb3NwZWN0aW9uKS4NCjxicj4NCkJ1dCB0aGUgQVMgYWxzbyBuZWVkcyB0byBkZWNp ZGUgd2hhdCB0byBwdXQgSU5UTyB0aGF0IHRva2VuLiBBcyBhIGNvbnNlcXVlbmNlLCB0aGUgQVMg Y2FuIGdldCB0aGF0IGluZm9ybWF0aW9uIGZyb20gYW55IG51bWJlciBvZiBwbGFjZXMuPGJyPg0K VGhlIGluZm9ybWF0aW9uIGNvdWxkIGJlIHByb3ZpZGVkIGluIGEgdHJ1c3RlZCB3YXkgYnkgdGhl IGVuZCB1c2VyIHRvIHRoZSBBUyDigJQgYnV0IHRoaXMgZG9lcyBOT1QgbmVjZXNzYXJpbHkgbWVh biB0aGF0IHRoZSBBUyBiZWxvbmdzDQo8YnI+DQp0byB0aGUgdXNlciBvciBpcyB1bmRlciB0aGVp ciBjb250cm9sLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+QmFzaWNhbGx5LCBJIHRoaW5rIHdl4oCZcmUgdHJ5aW5nIHRvIGhh cmQgdG8gbWFwIHRoZSBPQXV0aCBnZW5lcmFsLWNvbmNlcHQgb2YgdGhlIFJPIGhhdmluZyBhbiBh Y2NvdW50IGF0IHRoZSBBUyBhbmQgbG9nZ2luZyBpbiB0byBpdCBiZWZvcmUgYXV0aG9yaXppbmcg dGhlIHJlcXVlc3QuDQo8YnI+DQpJIHRoaW5rIHRoYXQgdGhlIGNhbGwgZm9yIOKAnGV2ZXJ5IHVz ZXIgdG8gaGF2ZSB0aGVpciBvd24gQVPigJ0gaXMgc3VjaCBhIGh1Z2Ugbm9uLXN0YXJ0ZXIgaW4g c28gbWFueSBkb21haW5zIHRoYXQgaXQgaGFtcGVycyB0aGUgc29sdXRpb24gc3BhY2UgaWYgdGhh dOKAmXMgd2hhdCB3ZSBwcmVzdW1lLg0KPGJyPg0KSXTigJlzIHVwIHRvIHRoZSBSUyB0byBkZWNp ZGUgd2hvIGl0IHRydXN0cywgbm90IHRoZSBlbmQgdXNlciBhbmQgbm90IHRoZSBSTy4mbmJzcDs8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkkgdGhpbmsgd2Ugc2hvdWxkIEFMTE9XIGl0LCBhbmQgd2UgY2FuIGJlIGNsZWFyZXIgaW4gR05B UCB0aGF0IHRoYXTigJlzIG9uZSBwb3NzaWJsZSBtb2RlbCwgYnV0IG5vdCB0aGUgb25seSBvbmUs IGFuZCBub3QgZXZlbiB0aGUgZ2VuZXJhbCBvbmUuDQo8YnI+DQpUaGUgQVMgbWFuYWdlcyBhbGwg b2YgdGhlIGluZm9ybWF0aW9uIGFuZCBpbnRlcmNvbm5lY3Rpb25zIG5lZWRlZCB0byBjcmVhdGUg YW4gYWNjZXNzIHRva2VuIHRoYXQgdGhlIFJTIHdpbGwgYWNjZXB0LCBhbmQgaXQgaXMgaW4gY2hh cmdlIG9mIHNpZ25hbGluZyB0byB0aGUgUlMgd2hhdCB0aGF0IHRva2Vu4oCZcyBnb29kIGZvci4N Cjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+PGZvbnQgY29sb3I9IiMwMDAwZmYiPkkg ZGlzYWdyZWU6IHRoZSBBUyBpcyBOT1QgaW4gY2hhcmdlIG9mIHNpZ25hbGluZyB0byB0aGUgUlMg d2hhdCB0aGF0IHRva2Vu4oCZcyBnb29kIGZvci4gSXQgaXMgdXAgdG8gdGhlIFJTIHRvIGRlY2lk ZSB3aGljaCBwcml2aWxlZ2VzIGl0IHdpbGwgYWNjZXB0DQo8YnI+DQphbW9uZyBhbGwgdGhlIHBy aXZpbGVnZXMgaW5jbHVkZWQgaW50byBhbiBhY2Nlc3MgdG9rZW4uPC9mb250Pjxicj4NCjwvcD4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBjbGFzcz0iIj5Ib3dldmVyLCBpZiB0aGUg QVMgY2FuIGxlYXJuIHRocm91Z2ggc29tZSBvdGhlciBtZWFucyB0aGF0IGEgc3BlY2lmaWMgaWRl bnRpZmllZCB1c2VyIGhhcyBjb25zZW50ZWQgYW5kIHByb3ZpZGVkIGFwcHJvcHJpYXRlIGluZm9y bWF0aW9uIGluIGEgdHJ1c3RlZCB3YXksDQo8YnI+DQp0aGVuIFRIQVQgaW5mb3JtYXRpb24gY2Fu IGJlIGJha2VkIGludG8gdGhlIHRva2VuIGJ5IHRoZSBBUy4g4oCUIGltcG9ydGFudGx5LDx1Pjxp PiBpbiBhIHdheSB0aGF0IHRoZSBSU+KAmXMgdGhlIEFTIHByb3RlY3RzIGNhbiB1bmRlcnN0YW5k PC9pPjwvdT4uDQo8YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwPjxmb250IGNvbG9yPSIj MDAwMGZmIj5JIGRpc2FncmVlOiBUcnVzdCByZWxhdGlvbnNoaXBzIGFyZSBub3QgYmlsYXRlcmFs IGJ1dCBvbmx5IHVuaWxhdGVyYWwuIEFuIEFTIGRvZXMgbm90IG5lZWQgdG8gaGF2ZSBhbnkgc3Bl Y2lmaWMgcHJpb3IgcmVsYXRpb25zaGlwIHdpdGggYSBnaXZlbiBSUy4NCjxicj4NCkl0IGlzIHVw IHRvIHRoZSBSUyhzKSB0byBkZWNpZGUgd2hpY2ggQVM8dT48Yj4ocyk8L2I+PC91PiBpdCB0cnVz dChzKSA8Yj5hbmQgZm9yIHdoaWNoIHByaXZpbGVnZXM8L2I+LjwvZm9udD48L3A+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgY2xhc3M9IiI+VGhpcyBsYXN0IGJpdCBpcyB3aGVyZSBn ZW5lcmFsIDx1PjxpPm9wYWNpdHkgb2YgdG9rZW5zPC9pPjwvdT4gaXMgaW1wb3J0YW50IGhlcmUu IFRoZXJl4oCZcyBhIG5hdHVyYWwgc2VjdXJpdHkgYm91bmRhcnkgdGhhdCBhcmlzZXMgZnJvbSB0 aGlzIG1vZGVsLiBXaGF0IEnigJltIHByb3Bvc2luZyBoZXJlIGlzIGp1c3QgdGhhdCB3ZeKAmXJl IG1vcmUgZXhwbGljaXQgYWJvdXQgd2hhdCBjYW4gYmUgcHV0IElOVE8gdGhhdCBib3VuZGFyeS4N CiBUaGF04oCZcyB3aGVyZSBJ4oCZbSBzZWVpbmcgYSBsb3Qgb2YgdGhpcyBpbm5vdmF0aW9uIGlu IHRoZSBTU0kgc3BhY2UgZml0dGluZy4gWW914oCZcmUgbm90IGNvbWluZyB1cCB3aXRoIHNvbWUg dW5pdmVyc2FsIGFjY2VzcyB0b2tlbiB0aGF0IHRoZSBSUyB3aWxsIGFjY2VwdCwgYnV0IHlvdeKA mXJlIGFibGUgdG8gcHJvdmlkZSB1bml2ZXJzYWwgY2xhaW1zIGFuZCBhcnRpZmFjdHMgdGhhdCBh biBBUyBjYW4gcHJvY2VzcyBhbmQNCjxpPjx1PnRyYW5zbGF0ZSBpbnRvIGEgdG9rZW4gdGhlIFJT IHdpbGwgYWNjZXB0IGFuZCBkbyB0aGUgcmlnaHQgdGhpbmcgd2l0aDwvdT48L2k+LjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPHA+PGZvbnQgY29sb3I9IiMwMDAwZmYiPllvdXIgYXJndW1lbnRhdGlv biBhYm91dCB0b2tlbiBvcGFjaXR5IGlzIG1ha2luZyB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBB UyBhbmQgdGhlIFJTIG5lZWQgdG8gaGF2ZSBhIHByaW9yIHJlbGF0aW9uc2hpcCBiZWZvcmUgYW55 IGFjY2VzcyBjYW4gdGFrZSBwbGFjZS48YnI+DQpXaGlsZSB0aGlzIHdhcyB2YWxpZCB3aXRoIE9B dXRoLCB0aGlzIGlzIG5vIG1vcmUgdmFsaWQgaW4gdGhlIGNvbnRleHQgb2YgR05BUC4mbmJzcDsg VGhlIGNsaWVudCBzaG91bGQgYmUgYWJsZSB0byBpbmZvcm0gdGhlIEFTIGFib3V0IHRoZSBhY2Nl c3MgdG9rZW4gZm9ybWF0KHMpIGFjY2VwdGFibGUgdG8gdGhlIFJTLg0KPGJyPg0KVGhlbiB0aGUg Y2xpZW50IG1heSBpbmRpY2F0ZSB0byB0aGUgQVMgdGhlc2UgYWNjZXB0YWJsZSBmb3JtYXRzLiBJ ZiB0aGUgUlMgYW5kIHRoZSBBUyBoYXZlIGFuIGFjY2VzcyB0b2tlbiBmb3JtYXQgaW4gY29tbW9u LCB0aGVuIHRoZSBwcm9jZXNzIG1heSBjb250aW51ZS4NCjxicj4NCjwvZm9udD48L3A+DQo8cD48 Zm9udCBjb2xvcj0iIzAwMDBmZiI+V2hlbiBvbmx5IGF0dHJpYnV0ZXMgKGkuZS4gbm90IHJpZ2h0 cykgYXJlIGJlaW5nIHJlcXVlc3RlZCB0byBhbiBBUyBieSB0aGUgY2xpZW50LCB0aGUgY2xpZW50 IGRvZXMgbm90IG5lZWQgdG8gZGlzY2xvc2UgdGhlIGlkZW50aXR5IG9mIHRoZSBSUyB0byB0aGUg QVMsDQo8YnI+DQp3aGljaCBoYXMgdGhlIG1ham9yIGFkdmFudGFnZSB0byBwcmV2ZW50IHRoZSBB UyB0byBhY3QgYXMgQmlnIEJyb3RoZXIuPC9mb250PjwvcD4NCjxwPjxmb250IGNvbG9yPSIjMDAw MGZmIj4mbmJzcDsmbmJzcDsmbmJzcDsgPHU+Tm90ZTwvdT46IHRoaXMgZG9lcyBub3QgcHJlY2x1 ZGUgdGhlIHVzZSBvZiByaWdodHMsIGluIHBhcnRpY3VsYXIgaW4gdGhlIGNvbnRleHQgb2YgYSBz aW5nbGUgb3JnYW5pemF0aW9uIG9yIGVudGVycHJpc2UuPC9mb250PjwvcD4NCjxwPjxmb250IGNv bG9yPSIjMDAwMGZmIj5EZW5pczwvZm9udD48L3A+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNw O+KAlCBKdXN0aW48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBGZWIgMjEs IDIwMjEsIGF0IDk6NDAgQU0sIEFkcmlhbiBHcm9wcGVyICZsdDs8YSBocmVmPSJtYWlsdG86YWdy b3BwZXJAaGVhbHRodXJsLmNvbSIgY2xhc3M9IiI+YWdyb3BwZXJAaGVhbHRodXJsLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJ4X0FwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0 ciIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNs YXNzPSIiPkhpIFRvcnN0ZW4sDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5UaGFuayB5b3UgZm9yIHJhaXNpbmcgYWxsIG9mIHRoZXNlIGV4Y2VsbGVu dCBwb2ludHMuIEkgaG9wZSB3ZSBjYW4gYWxsIGFuc3dlciB0aGVtIGFuZCBtYXliZSBldmVuIGFk ZCBhIHNlY3Rpb24gdG8gdGhlIHdpa2kuIEknbGwgc3RhcnQuLi48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPllvdSdyZSByaWdodCB0aGF0 IE9BdXRoIGRlcGxveW1lbnRzIGFsbW9zdCBleGNsdXNpdmVseSBwdXQgdGhlIEFTIGFuZCBSUyBp biB0aGUgc2FtZSBkb21haW4uIElmIE9BdXRoIHdlcmUgYWRlcXVhdGUgdG8gdG9kYXkncyBuZWVk cyB3ZSBwcm9iYWJseSB3b3VsZCBub3QgYmUgaGVyZSBkb2luZyBHTkFQLiBTaW5jZSBPQXV0aCwg d2UgaGF2ZSBpbmNyZWFzaW5nIHByaXZhY3kgY29uY2VybnMgYW5kIHNlY3VyaXR5IGRpc2FzdGVy cy4NCiBHRFBSLCBmb3IgZXhhbXBsZSwgc2VwYXJhdGVzIHRoZSByb2xlIG9mIGEgZGF0YSBjb250 cm9sbGVyIGZyb20gYSBkYXRhIHByb2Nlc3NvciBhbmQgdHJlYXRzIHRoZW0gYXMgc2VwYXJhdGUg bGVnYWwgZW50aXRpZXMuIFRvIG92ZXJzaW1wbGlmeSBHRFBSLCB0aGUgZGF0YSBwcm9jZXNzb3Ig aXMgc3BhcmVkIHByaXZhY3kgcmVzcG9uc2liaWxpdHkgYW5kIGNvc3QuPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Zb3UgYXJlIGFsc28g cmlnaHQgdG8gbWVudGlvbiBvcGVuIGJhbmtpbmcgYXMgYSB1c2UtY2FzZS4gT3BlbiBiYW5raW5n IGhhcyBub3QgYWRvcHRlZCBVTUEgMi4wIChvbiB3aGljaCBJIGhhdmUgd29ya2VkIGZvciBhbG1v c3QgYSBkZWNhZGUpIHdoaWNoIGlzIGJhc2VkIG9uIE9BdXRoLiBQU0QyIGFuZCBzaW1pbGFyIHJl Z3VsYXRpb25zIGRvIG5vdCB0aWUgdGhlIEFTIGFuZCBSUyB0byB0aGUgc2FtZSBzZWN1cml0eSBk b21haW4NCiBidXQgdGhleSBwcmVzdW1lIGEgbmFycm93IGZlZGVyYXRpb24gb2YgbGljZW5zZWQg KGFuZCByZWd1bGF0ZWQpIEFTcyBhcyBwYXltZW50IHByb2Nlc3NvcnMgZm9yIHN1YmplY3RzIHRv IGNob29zZSBhbW9uZy4gVGhpcyBjZW50cmFsaXphdGlvbiB0byByZWd1bGF0ZWQgZmlkdWNpYXJp ZXMgaXMgYSBwcml2YWN5IHRyYWRlLW9mZiB0aGF0IG1ha2VzIHNlbnNlIGluIGJhbmtpbmcuIFRo ZSBmaWR1Y2lhcnkgY2FuIGJlIGJvbmRlZCBzbyB0aGV5IGNhbg0KIHJlZnVuZCB0aGUgbW9uZXkg dG8gdGhlIHN1YmplY3QgaW4gY2FzZSBvZiBhIHNlY3VyaXR5IGJyZWFjaC4gVGhpcyBwcml2YWN5 LXNlY3VyaXR5IHRyYWRlb2ZmIGRvZXMgbm90IG1ha2Ugc2Vuc2UgaW4gaGVhbHRoY2FyZSBhbmQg b3RoZXIgZG9tYWlucyB3aGVyZSB0aGUgY29uc2VxdWVuY2VzIG9mIGEgYnJlYWNoIGFyZSBub3Qg ZWFzaWx5IHJldmVyc2VkLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+VGhpcyB0aHJlYWQgaXMgYWJvdXQgYWxpZ25pbmcgR05BUCBhbmQg U1NJLiBTU0kgZG9lcyBub3QgYWJpZGUgY2VudHJhbGl6YXRpb24sIGNlbnNvcnNoaXAsIG9yIHN1 cnZlaWxsYW5jZS4gSWYgR05BUCBtYWtlcyBhbnkgYXNzdW1wdGlvbnMgdGhhdCByZXN1bHQgaW4g ZWl0aGVyIGEgdGlnaHQgY291cGxpbmcgYmV0d2VlbiBBUyBhbmQgUlMgKHN1cnZlaWxsYW5jZSkg b3IgZXZlbiBhIGZlZGVyYXRlZCBmaWR1Y2lhcnkgKGNlbnRyYWxpemF0aW9uKQ0KIHdlIHdpbGwg bG9zZSBvdXQgb24gdGhlIGJlbmVmaXRzIG9mIHByb2dyZXNzIGluIGRpZ2l0YWwgaWRlbnRpdHkg dGhhdCBpcyBub3cgZHJpdmluZyBhIGxvdCBvZiBwdWJsaWMtc2VjdG9yIGluaXRpYXRpdmVzIGFu ZCBzdGFydGluZyB0byBibGVlZCBvdmVyIGludG8gcHJpdmF0ZSBzZWN0b3IgcHJhY3RpY2VzLiBa ZXJvIFRydXN0IEFyY2hpdGVjdHVyZSBpcyBhbiBleGFtcGxlIGFuZCBPQXV0aCBpcyBub3Qgd2Vs bCBzdWl0ZWQgZm9yIFpUQS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPkFzIHlvdSBzYWlkLCAmcXVvdDt0ZWNobmljYWxseSwgdGhlIHJl c3BlY3RpdmUgQVMgYW5kIFJTcyBzZXQgdXAgYSB0cnVzdCByZWxhdGlvbnNoaXAgYW5kIGFncmVl ZCBvbiB3YXlzIHRvIHNoYXJlIGF1dGhvcml6YXRpb24gYW5kIHVzZXIgZGF0YSBpbiBvcmRlciBb dG9dIGVuYWJsZSBzZWN1cmUgQVBJIGFjY2Vzcy4mcXVvdDsgVGhpcyBpcyB3aGVyZSBHTkFQIG9w ZXJhdGVzIGFuZCB3ZSBuZWVkIHRvIGF2b2lkIF9hbnlfIHJlc3RyaWN0aW9ucw0KIG9uIGVpdGhl ciB0aGUgQVMgb3IgdGhlIFJTIGJlaW5nIHNlbGYtc292ZXJlaWduLiBFeGFtcGxlcyBvZiBhIHNl bGYtc292ZXJlaWduIFJTIGNvdWxkIGJlIGEgcGVyc29uYWwgZGF0YSBzdG9yZSBvciBhbiBlbmNy eXB0ZWQgZGF0YSB2YXVsdCBsaWtlIHRoZSBvbmVzIHdlIHdvcmsgb24gaW4gVzNDL0RJRi4gQW55 IEFTIGNhbiBiZSBzZWxmLXNvdmVyZWlnbiBpZiB0aGUgc3ViamVjdCBjb250cm9scyBhbGwgb2Yg dGhlIHBvbGljaWVzIGFuZCB0aGVzZQ0KIHBvbGljaWVzIGFyZSBub3Qgc2hhcmVkLCBpbiB0aGUg c2FtZSB3YXkgYSBwcml2YXRlIGtleSBpcyBuZXZlciBub3Qgc2hhcmVkLiZuYnNwOzwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q29udGlu dWluZyB5b3VyIHF1b3RlOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNz PSJ4X2dtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4CjAuOGV4OyBib3JkZXIt bGVmdC13aWR0aDoxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBib3JkZXItbGVmdC1jb2xv cjpyZ2IoMjA0LDIwNCwyMDQpOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCkkgcmVhZCB5b3VyIGlkZWFz IHJlZ2FyZGluZyBzZWxmLXNvdmVyZWlnbiBBU3Mgd2l0aCBncmVhdCBpbnRlcmVzdCBhbmQgZ290 IHNvbWUgb2JzZXJ2YXRpb25zL3F1ZXN0aW9uczo8YnIgY2xhc3M9IiI+DQotIEEgcGVyc29uYWwg QVMgY291bGQgY2VydGFpbmx5IGNvbnRyb2wgYWNjZXNzIHRvIGEgcGVyc29u4oCYcyByZXNvdXJj ZXMuIEkgYXNzdW1lIHRoZSBwZXJzb27igJhzIFJTcyB3b3VsZCBvbmx5IGFjY2VwdCBhY2Nlc3Mg dG9rZW5zIHNpZ25lZCBieSB0aGUgUk8uIEFtIEkgcmlnaHQ/PGJyIGNsYXNzPSIiPg0KPC9ibG9j a3F1b3RlPg0KPGRpdiBjbGFzcz0iIj5ZZXMsIGFuZC4gVGhlcmUgaXMgZGViYXRlIGluIHZhcmlv dXMgU1NJIFdHcyB3aGV0aGVyIGEgUlMgc3VjaCBhcyBhbiBFbmNyeXB0ZWQgRGF0YSBWYXVsdCBz aG91bGQgcmVzcG9uZCB0byBjYXBhYmlsaXRpZXMgb3IgdG9rZW5zLiBFaXRoZXIgd2F5LCB0aGUg Uk8gaXMgaW4gY29udHJvbCBvZiB0aGUgc2lnbmF0dXJlIGJ1dCBhIHBlcnNvbmFsIEFTIGlzIGEg ZGVsZWdhdGUgb2YgdGhlIFJPIChlaXRoZXIgZGlyZWN0bHkgb3INCiB2aWEgYSBtb2JpbGUgdXNl ciBhZ2VudCkuIFdpdGggY2FwYWJpbGl0aWVzJm5ic3A7c3VjaCBhcyBaQ0FQLUxEIG9yIGJpc2N1 aXRzLCB0aGUgdG9rZW4gc2lnbmF0dXJlJm5ic3A7YWxsb3dzIGZvciBmaWx0ZXJlZCBkZWxlZ2F0 aW9uLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIGNsYXNzPSJ4X2dtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4CjAuOGV4 OyBib3JkZXItbGVmdC13aWR0aDoxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBib3JkZXIt bGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCi0gRG8geW91 IGVudmlzaW9uIHRoaXMgQVMgdG8gYmUgYWJsZSB0byBjb250cm9sIGFjY2VzcyB0byBhbnkga2lu ZCBvZiBSUz8gSG93IGlzIHRoZSBBUyBzdXBwb3NlZCB0byBrbm93IHdoYXQgYXV0aG9yaXphdGlv biBkYXRhIHRoaXMgUlMgbmVlZHMgaW4gb3JkZXIgdG8gcGVyZm9ybSBhY2Nlc3MgY29udHJvbCBk ZWNpc2lvbnM/IFdoYXQgZGF0YSB3aWxsIGJlIGV4Y2hhbmdlZD88YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPlllcy4gVGhlIHdob2xlIHBvaW50LCBhcyBmYXIgYXMg SSdtIGNvbmNlcm5lZCwgaXMgdG8gZGVzaWduIGh1bWFuIGNlbnRlcmVkIHN0YW5kYXJkcy4gVGhp cyBpcyBob3cgVzNDIGFuZCBJRVRGIGFyZSBkaWZmZXJlbnQuIE90aGVyIFNET3MgdGVuZCB0byBi ZSBvcGVyYXRlZCBmb3IgaW5zdGl0dXRpb25hbCBiZW5lZml0LiBBIHBlcnNvbi1jZW50ZXJlZCBB UyBtdXN0IHdvcmsgYWNyb3NzIGluc3RpdHV0aW9uYWwgZG9tYWlucy4mbmJzcDs8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoaXMsIGFz IHlvdSBwb2ludCBvdXQsIGJyaW5ncyB1cCB0aGUgcHJvYmxlbSBvZiBzY29wZS4gT250b2xvZ2ll cyBhbmQgZGF0YSBtb2RlbHMgYXJlLCBqdXN0aWZpYWJseSwgZG9tYWluLXNwZWNpZmljLiBJLCBm b3IgZXhhbXBsZSwgd29yayBhcm91bmQgdGhlIEhMNyBkYXRhIG1vZGVsIHN0YW5kYXJkcyBhbmQg QVBJcyBsaWtlIEZISVIgdGhhdCBhcmUgY29udHJvbGxlZCBieSBoZWFsdGhjYXJlIGJ1c2luZXNz IGludGVyZXN0cy4NCiBJdCdzIHVucmVhc29uYWJsZSB0byBleHBlY3QgYSBnZW5lcmFsIHNvbHV0 aW9uIHRvIHRoZSBkYXRhIG1vZGVsIHByb2JsZW0sIGFsdGhvdWdoIGZvbGtzIG9mIHRoZSBMaW5r ZWQgRGF0YSBwZXJzdWFzaW9uIG1pZ2h0IGRpc2FncmVlLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RXZlcnkgUlMgZ2V0cyB0byBkZWNp ZGUgd2hhdCBkYXRhIG1vZGVscyBhbmQgb250b2xvZ2llcyBpdCBzdXBwb3J0cy4gVGhlc2UgZGVj aXNpb25zIGFyZSBwdWJsaWMgYW5kIHNvbWV0aW1lcyBzdGFuZGFyZGl6ZWQgZm9yIHRoZSBiZW5l Zml0IG9mIHRoZSBjbGllbnRzLiBBIHBlcnNvbidzIEFTIG11c3QgcmVhZCBhbmQgbWF5YmUgdW5k ZXJzdGFuZCB0aGUgUlMgZGF0YSBtb2RlbCBpbiBvcmRlciB0byBpc3N1ZSB0b2tlbnMNCiBqdXN0 IGxpa2UgdGhlIGNsaWVudCBuZWVkcyB0byBkbyBpbiBvcmRlciB0byBtYWtlIGEgcmVxdWVzdCB0 byB0aGUgQVMuIEluIG91ciBISUUgb2YgT25lIFRydXN0ZWUgcHJvamVjdCwgd2UgYWxsb3cgdGhl IHNlbGYtc292ZXJlaWduIHN1YmplY3QgdG8gaW5oZXJpdCBBUyBwb2xpY2llcyBmcm9tIHNlbGYt c292ZXJlaWduIGNvbW11bml0aWVzIHRoZXkgY2hvb3NlIGFuZCB0aGVuIG1vZGlmeSB0aGUgcG9s aWNpZXMgaWYgdGhleSB3YW50LiBJbiB0aGlzDQogd2F5LCBjb21tdW5pdGllcyBjb21wZXRlIGZv ciBtZW1iZXJzIG9uIHRoZSBiYXNpcyBvZiBwb2xpY3kgYnVuZGxlcyB0aGUgc2FtZSB3YXkgY2h1 cmNoZXMgY29tcGV0ZSBmb3IgY29uZ3JlZ2FudHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9InhfZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MHB4IDBweCAwcHgKMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVy LWxlZnQtc3R5bGU6c29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IHBh ZGRpbmctbGVmdDoxZXgiPg0KLSBIb3cgd291bGQgdGhpcyBwZXJzb24gZGVsZWdhdGUgYWNjZXNz IHRvIGhlciByZXNvdXJjZXMgdG8gc29tZW9uZSBlbHNlPzxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxkaXYgY2xhc3M9IiI+VGhlcmUgYXJlIHR3byAmcXVvdDtwZXJzb25zJnF1b3Q7IHRv IGNvbnNpZGVyLiBUaGUgUk8gZGVsZWdhdGVzIHRvIGFuIFJRLiBCdXQgdGhlIFJRLCBpbiByZWFs IGxpZmUsIGlzIHBhcnQgb2YgYSB0ZWFtIGFuZCBvZnRlbiBkZWxlZ2F0ZXMgdG8gYXNzb2NpYXRl cy4gV2l0aCBvciB3aXRob3V0IGNhcGFiaWxpdGllcywgR05BUCBuZWVkcyB0byBkZWFsIHdpdGgg dGhpcyByZWFsaXR5IHRoYXQgUk8gYW5kIFJRIHVzZXIgYWdlbnRzIG1heSBiZQ0KIGRpZmZlcmVu dCBmcm9tIHRoZSBjbGllbnQgdGhhdCBhY3R1YWxseSBwcmVzZW50cyBhIHRva2VuIHRvIHRoZSZu YnNwO1JTLiBTb21lIG9mIHRoaXMgZGlmZmVyZW5jZSBiZXR3ZWVuIHVzZXIgYWdlbnRzIGFuZCBj bGllbnRzIHdlIG1heSBiZSBhYmxlIHRvIGtlZXAgb3V0IG9mIGJhbmQuPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9InhfZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgKMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRo OjFweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQs MjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0KLSBBcmUgeW91IGF3YXJlIG9mIGRlcGxveW1l bnRzIGltcGxlbWVudGluZyB0aGlzIHBoaWxvc29waHk/PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1 b3RlPg0KPGRpdiBjbGFzcz0iIj5PdGhlciB0aGFuIG91ciBISUUgb2YgT25lIGRlbW9uc3RyYXRp b24gcHJvamVjdCBpbiBoZWFsdGhjYXJlLCBuby4gV2Ugc3RhcnRlZCBISUUgb2YgT25lIGJlZm9y ZSBTU0kgaW4gb3JkZXIgdG8gZHJpdmUgdGhlIHRyYW5zaXRpb24gZnJvbSBVTUEgdG8gVU1BIDIu MCBhbmQgaW5mb3JtIHZhcmlvdXMgaGVhbHRoY2FyZSByZWd1bGF0b3J5Jm5ic3A7cHJpb3JpdGll cy4gV2UgdGhlbiBqdW1wZWQgb24gU1NJIGltbWVkaWF0ZWx5IGFuZA0KIGFkZGVkIGl0IHRvIHRo ZSBVTUEgMiBBUyB3ZSBjYWxsIFRydXN0ZWUuIE5vdyB3ZSBhcmUgdHJ5aW5nIHRvIGFsaWduIFNT SSBhbmQgR05BUCBpbiBvcmRlciB0byBlbmFibGUgaHVtYW4tY2VudGVyZWQgcHJvdG9jb2xzIGFu ZCB6ZXJvLXRydXN0IGFyY2hpdGVjdHVyZS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5i c3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0ieF9nbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp bjowcHggMHB4IDBweAowLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6MXB4OyBib3JkZXItbGVmdC1z dHlsZTpzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTsgcGFkZGluZy1s ZWZ0OjFleCI+DQotIFdoYXQgYXJlIHRoZSBpbXBsaWNhdGlvbnMgaW4gdGVybXMgb2YgdXNlciBl eHBlcmllbmNlPzwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+UmlnaHQgbm93LCB0aGUgaHVt YW4tY2VudGVyZWQgdXNlciBleHBlcmllbmNlIGFzc3VtZXMgYSBzZWN1cmUgZWxlbWVudCBhbmQg d2ViIGJyb3dzZXIgYXMgdXNlciBhZ2VudHMgb24gYSBtb2JpbGUgZGV2aWNlLiBOZWl0aGVyIG9m IHRoZXNlIGlzIHJlYWRpbHkgYWNjZXNzaWJsZSZuYnNwO2FzIGEgc2VydmVyIG5vciBhcmUgdGhl eSBkZXNpZ25lZCB0byBhY2NlcHQgY29kZSBwbHVnLWlucyB0aGF0IHJlcHJlc2VudCB0aGUgcG9s aWNpZXMNCiBvZiBhbiBBUy4gT25lIG1ham9yIGV4Y2VwdGlvbiBpcyBwZW9wbGUgYWRkaW5nIGFk dmVydGlzaW5nIGFuZCBzdXJ2ZWlsbGFuY2UgYmxvY2tlcnMgbGlrZSBFRkYgUHJpdmFjeSBCYWRn ZXIgdG8gdGhlaXIgYnJvd3Nlci4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIHVzZXIgZXhwZXJpZW5jZSBp bXBsaWNhdGlvbnMgb2YgaGF2aW5nIFNTSSBkYXRhIG1vZGVsIHN0YW5kYXJkcyBhbmQgR05BUCBw cm90b2NvbCBzdGFuZGFyZHMgaXMgdGhhdCB0b2RheSdzIHBhc3N3b3JkIG1hbmFnZXJzIChJIGhh dmUgMjUwIFJTIHJlbGF0aW9uc2hpcHMgaW4gbWluZSkgd2lsbCBldm9sdmUgdG8gYWxzbyBjb250 cm9sIGFuIEFTIGFnZW50LiBKdXN0IGxpa2UgSSBtaWdodCByZWdpc3RlciBhIFczQyBESUQNCiB3 aXRoIGFuIFJTIGluc3RlYWQgb2YgYW4gZW1haWwgYWRkcmVzcywgbXkgcG9saWN5IG1hbmFnZXIg bWlnaHQgZGlzcGxheSB0byBtZSB0aGUgdG9rZW4gcG9saWNpZXMgdGhhdCB3aWxsIGJlIGFwcGxp ZWQgYnkgbXkgQVMgdG8gdGhlIHBlcnNvbmFsIGRhdGEgSSBjYW4gY29udHJvbCBhdCB0aGF0IFJT LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+SW4gc29tZSBjYXNlcywgbXkgQVMgd2lsbCBhbGxvdyBtZSB0byBtb2RpZnkgdGhv c2UgcG9saWNpZXMganVzdCBsaWtlIHRoZSBvYm5veGlvdXMgY29va2llIHBvbGljeSBzZXR0aW5n cyBkbyB0b2RheS4gVGhlIEJJRyBkaWZmZXJlbmNlIHdpdGggR05BUCBpcyB0aGF0IEkgY2hvb3Nl IG15IEFTIHNlcGFyYXRlbHkgZnJvbSB0aGUgUlMgc28gdGhlIGRhcmsgcGF0dGVybnMgYXNzb2Np YXRlZCB3aXRoIHRvZGF5J3MgY29va2llDQogcG9saWNpZXMgZXhwZXJpZW5jZSBhcmUgbm8gbG9u Z2VyIHBvc3NpYmxlLiBHTkFQIG1lYW5zIHRoZSBSUyBleHBvc2VzIGFuIEFQSSByYXRoZXIgdGhh biBhIFVJLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+SSd2ZSBnb25lIG9uIGZhciB0b28gbG9uZyB0byBhZGRyZXNzIHRoZSBpc3N1ZSBv ZiB0aGUgQVMgYXMgYW4gaWRlbnRpdHkgcHJvdmlkZXIuIEl0J3MgZmFpciB0byB0aGluayBvZiBp dCB0aGF0IHdheS4gQXMgaXQgdHVybnMgb3V0LCBpbiB0aGUgU1NJIFNlY3VyZSBEYXRhIFN0b3Jh Z2UgV0csIHdlIGFyZSBkZWJhdGluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGFuIEVuY3J5cHRl ZCBEYXRhIFZhdWx0IGFuZCBhbiBJZGVudGl0eQ0KIEh1Yi4gQXMgZmFyIGFzIEknbSBjb25jZXJu ZWQsIHRoZSBJZGVudGl0eSBIdWIgaXMgbW9zdGx5IGEgR05BUCBBUy4gSm9pbiB1cyBvbiBUaHVy c2RheXMgYXQgNCBQTSBFVCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbGlzdHMuaWRlbnRpdHkuZm91 bmRhdGlvbi9nL3Nkcy13Zy93aWtpL0hvbWUiIGNsYXNzPSIiPmh0dHBzOi8vbGlzdHMuaWRlbnRp dHkuZm91bmRhdGlvbi9nL3Nkcy13Zy93aWtpL0hvbWU8L2E+Jm5ic3A7PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BZHJpYW48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSJ4X2dtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNz PSJ4X2dtYWlsX2F0dHIiPk9uIFN1biwgRmViIDIxLCAyMDIxIGF0IDQ6MzQgQU0gVG9yc3RlbiBM b2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0 YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3 cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJ4X2dtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgKICAgICAgICAgICAgICAgICAgMHB4CjAuOGV4OyBi b3JkZXItbGVmdC13aWR0aDoxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBib3JkZXItbGVm dC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJh dXRvIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+QW0gMTkuMDIuMjAyMSB1bSAyMzo1MCBzY2hyaWViIEFkcmlh biBHcm9wcGVyICZsdDs8YSBocmVmPSJtYWlsdG86YWdyb3BwZXJAaGVhbHRodXJsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiIGNsYXNzPSIiPmFncm9wcGVyQGhlYWx0aHVybC5jb208L2E+Jmd0Ozo8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+77u/DQo8 ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5JIGFncmVlIHdpdGggdGhlJm5ic3A7Zmlyc3QmbmJzcDt0 d28gb2YgSnVzdGluJ3MgcmVzcG9uc2VzIGJ1dCBub3QgdGhlIGxhc3Qgb25lLg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SXQncyBjb25mdXNpbmcg dG8gdGhpbmsgdGhhdCB0aGVyZSBhcmUgbW9yZSBSUyB0aGFuIEFTLjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPnRoZSBPQXV0aCBkZXBsb3ltZW50cyBJ4oCYbSBhd2FyZSBvZiB0eXBp Y2FsbHkgaGF2ZSBtdWNoIG1vcmUgUlNzIHRoYW4gQVNzLiBXaHk/IEJlY2F1c2UgQVMgYW5kIGEg c2V0IG9mIFJTcyBiZWxvbmcgdG8gdGhlIHNhbWUgc2VjdXJpdHkgZG9tYWluIChlLmcuIGEgY2Vy dGFpbiBidXNpbmVzcykgYW5kIGl04oCZcyB0aGUgQVPigJlzIHJlc3BvbnNpYmlsaXR5IHRvIGVu c3VyZSBzZWN1cmUgYW5kIGNvbnZlbmllbnQgYWNjZXNzIHRvDQogdGhlIEFQSXMgcHJvdmlkZWQg YnkgdGhpcyBSU3MuIEZvciBleGFtcGxlOiB0aGVyZSBpcyBhIEFTIGNvbnRyb2xsaW5nIGFjY2Vz cyB0byBhIGNsb3VkLCBzdHJlYW1pbmcsIGFuZCBtZXNzYWdpbmcgc2VydmljZXMgb2YgdGhlIHNh bWUgYnVzaW5lc3MuIEluIGNhc2Ugb2Ygb3BlbiBiYW5raW5nLCB0aGUgYmFua+KAmHMgQVMgaXMg KG9uIGJlaGFsZiBvZiB0aGUgdXNlcikgYXV0aG9yaXppbmcgYWNjZXNzIHRvIEFQSXMgZm9yIGFj Y291bnQgaW5mb3JtYXRpb24NCiBhcyB3ZWxsIGFzIHBheW1lbnQgaW5pdGlhdGlvbiBhbmQgcG90 ZW50aWFsbHkgb3RoZXIgc2VydmljZXMuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UZWNobmljYWxseSwgdGhlIHJlc3BlY3Rp dmUgQVMgYW5kIFJTcyBzZXQgdXAgYSB0cnVzdCByZWxhdGlvbnNoaXAgYW5kIGFncmVlZCBvbiB3 YXlzIHRvIHNoYXJlIGF1dGhvcml6YXRpb24gYW5kIHVzZXIgZGF0YSBpbiBvcmRlciBlbmFibGUg c2VjdXJlIEFQSSBhY2Nlc3MuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHJlYWQgeW91ciBpZGVhcyByZWdhcmRpbmcgc2VsZi1zb3Zl cmVpZ24gQVNzIHdpdGggZ3JlYXQgaW50ZXJlc3QgYW5kIGdvdCBzb21lIG9ic2VydmF0aW9ucy9x dWVzdGlvbnM6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi0gQSBwZXJzb25hbCBBUyBjb3VsZCBjZXJ0 YWlubHkgY29udHJvbCBhY2Nlc3MgdG8gYSBwZXJzb27igJhzIHJlc291cmNlcy4gSSBhc3N1bWUg dGhlIHBlcnNvbuKAmHMgUlNzIHdvdWxkIG9ubHkgYWNjZXB0IGFjY2VzcyB0b2tlbnMgc2lnbmVk IGJ5IHRoZSBSTy4gQW0gSSByaWdodD88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBEbyB5b3UgZW52 aXNpb24gdGhpcyBBUyB0byBiZSBhYmxlIHRvIGNvbnRyb2wgYWNjZXNzIHRvIGFueSBraW5kIG9m IFJTPyBIb3cgaXMgdGhlIEFTIHN1cHBvc2VkIHRvIGtub3cgd2hhdCBhdXRob3JpemF0aW9uIGRh dGEgdGhpcyBSUyBuZWVkcyBpbiBvcmRlciB0byBwZXJmb3JtIGFjY2VzcyBjb250cm9sIGRlY2lz aW9ucz8gV2hhdCBkYXRhIHdpbGwgYmUgZXhjaGFuZ2VkPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4t IEhvdyB3b3VsZCB0aGlzIHBlcnNvbiBkZWxlZ2F0ZSBhY2Nlc3MgdG8gaGVyIHJlc291cmNlcyB0 byBzb21lb25lIGVsc2U/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi0gQXJlIHlvdSBhd2FyZSBvZiBk ZXBsb3ltZW50cyBpbXBsZW1lbnRpbmcgdGhpcyBwaGlsb3NvcGh5PzwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4tIFdoYXQgYXJlIHRoZSBpbXBsaWNhdGlvbnMgaW4gdGVybXMgb2YgdXNlciBleHBlcmll bmNlPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+SW4gbXkgZXhwZXJpZW5jZSBjb3VwbGluZyBiZXR3ZWVuIEFTIGFuZCBSUyBpcyB2ZXJ5 IHRpZ2h0LiBJIGhhdmUgYSBoYXJkIHRpbWUgdG8gc2VlIGhvdyBzZWxmLXNvdmVyZWlnbiBBU3Mg d291bGQgd29yay4gSXQgZmVlbHMgbGlrZSBzdWNoIGFuIEFTIGluIHRoZSBlbmQgaXMgYW4gaWRl bnRpdHkgcHJvdmlkZXIgb2Ygc29tZSBzb3J0LCB3aGljaCBicmluZ3MgbWUgdG8gd2hhdCBKdXN0 aW4gcHJvcG9zZWQuIEkgd291bGQNCiBhc3N1bWUgdXNpbmcgU1NJIGNyZWRlbnRpYWxzIHRvIGF1 dGhlbnRpY2F0ZSB0b3dhcmRzIEFTcyBpcyBmZWFzaWJsZSBhbmQgbWlnaHQgaGF2ZSB2YWx1ZSBi dXQgSeKAmG0gc2tlcHRpY2FsIGFib3V0IHRoZSBBUyBwYXJ0LjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+YmVzdCByZWdhcmRzLDwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5Ub3JzdGVuLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYg ZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5Gcm9tIGEgaHVtYW4tY2VudGVyZWQg KGFuZCBob3BlZnVsbHkgSUVURikgcGVyc3BlY3RpdmUsIGVhY2ggcGVyc29uIG1pZ2h0IGNvbnRy b2wgb3Igc3BlY2lmeSBhIGRpZmZlcmVudCBBUyBmb3IgZWFjaCBvZiB0aGVpciBwZXJzb25hcyBv ciBmb3IgZWFjaCBjaGlsZCBvciBpbmNvbXBldGVudCBkZWxlZ2F0ZSBvZiB0aGVtIGFzIGd1YXJk aWFuLiBXZSdyZSBmYW1pbGlhciB3aXRoIHNlcGFyYXRlIGdtYWlsIGFkZHJlc3Nlcw0KIGZvciBl YWNoIHBlcnNvbmEuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5BU3Mgd2lsbCBiZSBzZWxmLXNvdmVyZWlnbiAoYXMgaW4gU1NJKSwgZmlk dWNpYXJ5IChhcyBpbiBhIGN1c3RvZGlhbCBiaXRjb2luIHdhbGxldCksIG9yIGJyb2tlcnMgKGFz IGluIGRhdGEgYnJva2VycyBhbmQgc3VydmVpbGxhbmNlIGNhcGl0YWxpc20pLiBBbnkgUlMgdGhh dCBpcyB3aWxsaW5nIHRvIGhhdmUgYSByZWN1cnJpbmcgcmVsYXRpb25zaGlwIHdpdGggYSBwZXJz b25hIGNvdWxkIGFjY2VwdCBhIEdOQVAgQVMgZW5kcG9pbnQNCiBpbnN0ZWFkIG9mIGFuIGVtYWls IGFkZHJlc3MuIFRoaXMgaXMgZWFzaWVzdCB1c2luZyBIVFRQLCBidXQgR05BUCBuZWVkIG5vdCBl eGNsdWRlIG90aGVyIFJTIC8gQVMgQVBJcyBhbmQgdHJhbnNwb3J0cy4gRGVzaWduaW5nIGFyb3Vu ZCB0aGUgdW5jZW5zb3JlZCBzcGVjaWZpY2F0aW9uJm5ic3A7b2Ygb25lJ3MgQVMgYXMgYSBodW1h biByaWdodCB3b3VsZCBncmVhdGx5IHNpbXBsaWZ5IG1hbnkgYXNwZWN0cyBvZiBHTkFQIGFkb3B0 aW9uLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+VGhhdCBzYWlkLCBHTkFQIHNob3VsZCBub3QgaWdub3JlIHRoZSBSUyBidXNpbmVzcyBv ciBqdXJpc2RpY3Rpb25hbCZuYnNwO3JlYXNvbnMgdG8gbGltaXQgdGhlIGF1dGhvcml0eSBvZiB0 aGUgQVMuIFVNQSAyLjAgc3BlbnQgeWVhcnMgZGFuY2luZyBhcm91bmQgdGhpcyBpc3N1ZSB3aXRo IGlkZWFzIGxpa2UgJnF1b3Q7Y2FzY2FkaW5nJnF1b3Q7IEFTIGFuZCB2YXJpb3VzIGNlbnRyYWxp emVkIG9yIGZlZGVyYXRlZCBBUyBjb25jZXB0cy4gTXkgY29uY2x1c2lvbg0KIGlzIHRoYXQgYW55 IFJTIGNhbiBhbHdheXMgZG8gd2hhdGV2ZXIgaXQgd2FudHMgYW5kIHRoZXJlJ3Mgbm90IG11Y2gg dGhlIGF1dGhvcml6YXRpb24gcHJvdG9jb2wgY2FuIGhlbHAgd2l0aCBvdGhlciB0aGFuIHNwZWNp ZnlpbmcgYSBub3RpZmljYXRpb24gZW5kcG9pbnQgc28gdGhhdCBhbiBSUyBjYW4gd2FybiAoYW5k IHNlZWsgY29uZmlybWF0aW9uKSBvciBsb2cgdmFyaW91cyBleGNlcHRpb25zLiBUaGlzIHR1cm5z IG91dCB0byBiZSwgYWZ0ZXINCiBhIHllYXIgb2YgdGVzdGltb255LCB0aGUgcmVndWxhdGlvbiB0 aGF0IGFwcGxpZXMgdG8gSElQQUEgUlMgQVBJcyBpbiB0aGUgVVMuIEZvciB0aGlzIHJlYXNvbiBH TkFQIG1pZ2h0IGluY2x1ZGUgYSBub3RpZmljYXRpb24gcHJvdG9jb2wgaW4gdGhlIEFTIHNwZWNp ZmljYXRpb24sIG9yIG5vdC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPkkgcHJvcG9zZSB0aGF0IGVtYnJhY2luZyBhIHNlbGYtc292ZXJl aWduIGFnZW50IGlzIGtleSB0byBoYXJtb25pemluZyB0aGUgU1NJIGFuZCBHTkFQIHN0YW5kYXJk cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkFkcmlhbjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJ4X2dt YWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJ4X2dtYWlsX2F0dHIiPk9uIEZyaSwg RmViIDE5LCAyMDIxIGF0IDI6MzAgUE0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmpyaWNoZXJAbWl0LmVk dTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9 InhfZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgKMC44ZXg7IGJvcmRlci1s ZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IGJvcmRlci1sZWZ0LWNvbG9y OnJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBjbGFzcz0iIiBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7IGxpbmUtYnJlYWs6YWZ0ZXItd2hpdGUtc3BhY2UiPlRv YmlhcywgdGhhbmtzIGZvciB0aGUgZ3JlYXQgb2JzZXJ2YXRpb25zLiBTb21lIHJlYWN0aW9ucyBp bmxpbmUgYmVsb3cuPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gRmViIDE4 LCAyMDIxLCBhdCA3OjU5IFBNLCBUb2JpYXMgTG9va2VyICZsdDs8YSBocmVmPSJtYWlsdG86dG9i aWFzLmxvb2tlckBtYXR0ci5nbG9iYWwiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj50b2JpYXMu bG9va2VyQG1hdHRyLmdsb2JhbDwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPkp1c3Rpbiw8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHRoaW5rIHRoaXMgaXMgYSBncmVhdCBhbmQgdGltZWx5IGNv bnZlcnNhdGlvbiB0byBiZSBoYXZpbmcgZ2l2ZW4gdGhlIGN1cnJlbnQgaW50ZXJlc3QgYXJvdW5k IFNTSSBhbmQgZWZmb3J0cyBsaWtlIFNJT1AsIEkgaGF2ZSBiZWVuIGRvaW5nIHF1aXRlIGEgYml0 IG9mIHdvcmsgaW4gdGhpcyBzcGFjZSBhcyBvZiByZWNlbnQsIHNvIHRob3VnaHQgSSdkIGFkZCBh IGZldyBvZiB0aGUgb2JzZXJ2YXRpb25zIHRoYXQgSSd2ZSBtYWRlLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCkluIG15IG9waW5pb24gU0lPUCB3YXMgcmVhbGx5IGEgYnVja2V0IGZvciBz b2x2aW5nIHF1aXRlIGEgZmV3IGRpZmZlcmVudCBwcm9ibGVtcywgbm90IGp1c3Qgb25lLiBJbiBw YXJ0aWN1bGFyIEkgdGhpbmsgaXRzIGludGVudCB3YXMgdG8gc29sdmUgMyBtYWpvciBvbmVzOjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjEuIEVuYWJsaW5nIHBvcnRhYmxlIGlkZW50aXRp ZXM8YnIgY2xhc3M9IiI+DQoyLiBTb2x2aW5nIHRoZSBOQVNDQVIgcHJvYmxlbTxiciBjbGFzcz0i Ij4NCjMuIEV4cGxvcmluZyBkaWZmZXJlbnQgZGVwbG95bWVudCBtb2RlbHMgZm9yIHRoZSBwcm92 aWRlcjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRvIGRyaWxsIGRvd24gYnJpZWZseSBv biB0aGVzZSwgbm90ZSBtdWNoIG9mIG15IHRlcm1pbm9sb2d5IGlzIE9wZW5JRCBiYXNlZCBkdWUg dG8gU0lPUHMgb3JpZ2luJm5ic3A7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGIgY2xh c3M9IiI+RW5hYmxpbmcgcG9ydGFibGUgaWRlbnRpdGllcyA8L2I+LSBJbiBnZW5lcmFsIHRvZGF5 IGluIHRoZSBjYXNlIG9mIE9wZW5JRCwgdGhlIGVuZC11c2VycyBpZGVudGl0eSBhcyB1bmRlcnN0 b29kIGJ5IGEgcmVseWluZyBwYXJ0eSBpcyBzY29wZWQgd2l0aGluIHRoZSBkb21haW4gb2YgdGhl IHByb3ZpZGVyLiBXaGljaCBtZWFucyBpZiB0aGF0IHByb3ZpZGVyIGdvZXMgb3V0IG9mIGJ1c2lu ZXNzIG9yIGZvciB3aGF0ZXZlciByZWFzb24NCiBkZWNpZGVzIHRvIG5vIGxvbmdlciBvZmZlciB0 aGUgc2FtZSBpZGVudGl0eSBzZXJ2aWNlcyB0byB0aGUgRW5kLVVzZXIsIHRoZWlyIGlkZW50aXR5 IGlzIGVzc2VudGlhbGx5IGdvbmUuIFdoaWxzdCB0aGVyZSBoYXMgYmVlbiBzb21lIGludGVyZXN0 aW5nIHJlbGF0ZWQgd29yayBmcm9tIGdyb3VwcyBsaWtlIE1PRFJOQSBvbiBzb2x1dGlvbnMgdG8g Y29tYmF0IHRoaXMgbGlrZSAnQWNjb3VudCBQb3J0aW5nJywgdGhleSBvZnRlbiBhc3N1bWUgdGhl DQogb2xkIHByb3ZpZGVyIHJlbWFpbnMgb25saW5lIGFuZCB3aWxsaW5nIHRvIGZhY2lsaXRhdGUg aW4gdGhlIGFjY291bnQgcG9ydGluZyBwcm9jZXNzIHNvIHRoYXQgdGhlIEVuZC1Vc2VyIGNhbiBt aWdyYXRlIHRvIGEgbmV3IHByb3ZpZGVyLiBTSU9QIGFjdHVhbGx5IGVsZWN0ZWQgdG8gZG8gc29t ZXRoaW5nIGRpZmZlcmVudCBoZXJlIGJ5IHVzaW5nIGNyeXB0b2dyYXBoeSwgaW5zdGVhZCBvZiB0 aGUgRW5kLVVzZXIgaWRlbnRpZmllciBiZWluZyBzb21ldGhpbmcNCiBsaWtlIGEgR1VJRCBhc3Nl cnRlZCB3aXRoaW4gdGhlIGRvbWFpbiBvZiB0aGUgcHJvdmlkZXIsIFNJT1AgZGVmaW5lZCB0aGlz IGluc3RlYWQgYXMgYSBwdWJsaWMga2V5IGZpbmdlcnByaW50IGFzc29jaWF0ZWQgdG8gYSBwcml2 YXRlIGtleSB0aGF0J3MgYXNzdW1lZCB0byBiZSB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUgdXNl ci4gSW4gZG9pbmcgc28gdGhlIGlkZW50aXR5IGl0c2VsZiBiZWNvbWVzIHBvcnRhYmxlIGJldHdl ZW4gcHJvdmlkZXJzDQogYnkgdHJhbnNmZXJyaW5nIHRoZSBhc3NvY2lhdGVkIHByaXZhdGUga2V5 LiBOb3cgdGhpcyBhcHByb2FjaCBkb2VzIGhhdmUgZHJhd2JhY2tzIGFuZCBhcmd1YWJseSBlbmNv dXJhZ2VzIHdoYXQgbWFueSB3b3VsZCByZWZlciB0byBhcyBiYWQgY3J5cHRvZ3JhcGhpYyBwcmFj dGlzZSBieSBub3QgYWxsb3dpbmcgYW55IHdheSB0byBkbyBrZXkgcm90YXRpb24sIGhvd2V2ZXIg dGhlIGlkZWEgd2FzIHRoZXJlLiZuYnNwOw0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+SG93IEdOQVAgY2FuIHNvbHZlIGZvciB0 aGlzPzwvYj4gQnkgaGF2aW5nIGZsZXhpYmlsaXR5IGFyb3VuZCBob3cgdGhlIHJlc291cmNlIG93 bmVyIC8gRW5kLVVzZXIgaXMgcmVmZXJyZWQgdG8gYnkgdGhlIEF1dGhvcml6YXRpb24gc2VydmVy IChlLmcgYWxsb3cgdGhlIGlkZW50aWZpZXIgdG8gYmUgc29tZXRoaW5nIGxpa2UgYSBwdWJsaWMg a2V5IG9yIGEgcmVzb2x2YWJsZSBpZGVudGlmaWVyIHRvIHB1YmxpYw0KIGtleXMgc3VjaCBhcyBh IERJRCk8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHBl cnNvbmFsbHkgdGhpbmsgdGhhdCBHTkFQIHNob3VsZCBiZSBhIGZsZXhpYmxlIDpjYXJyaWVyOiBv ZiBpZGVudGlmaWVycyBhbmQgb3RoZXIgYml0cyBvZiBpZGVudGl0eSBpbmZvcm1hdGlvbi4gVGhp cyBpcyB0aGUgbWFpbiByZWFzb24gd2Ugd2VudCB3aXRoIHRoZSBTdWJqZWN0IElkZW50aWZpZXJz IGRyYWZ0IGZyb20gU0VDRVZFTlQ6IGl04oCZcyBzZXQgdXAgdG8gdGFsayBhYm91dCBhIHZhcmll dHkgb2YgZGlmZmVyZW50DQoga2luZHMgb2YgaWRlbnRpZmllcnMsIGFsbCBvZiB0aGVtIGFzc2Vy dGVkIGluIHRoZSBjb250ZXh0IG9mIHRoZSBBUy4gSWYgdGhlcmXigJlzIGEgZGVmaW5pdGlvbiBm b3IgYSBESUQgVVJMIG9yIGEgSldLIGluIHRoZSBzdWJfaWRzIG9iamVjdCBzdHJ1Y3R1cmUsIEdO QVAgd291bGQgYmUgYWJsZSB0byBqdXN0IHVzZSBpdCBkaXJlY3RseSBhbG9uZ3NpZGUgZXZlcnkg b3RoZXIgZm9ybWF0LiBJIGhhdmVu4oCZdCBzZWVuIHRob3NlIHByb3Bvc2VkIHlldCwNCiBidXQg aXQgd291bGQgYmUgZWFzeSB0byBkbyBhbmQsIGluIG15IG1pbmQsIHdvdWxkIGJlIGEgYmV0dGVy IHNvbHV0aW9uIHRoYW4gdGhlIHBvcnRhYmxlIGlkZW50aWZpZXJzIHByb3Bvc2FsIHRoYXQgd2Fz IHJlY2VudGx5IGJyb3VnaHQgdXAgaW4gdGhlIEZBUEkgd29ya2luZyBncm91cCBpbiBPSURGLiAo QSBzaWRlIG5vdGUsIGJ1dCB0aGUgbWFpbiBwcm9ibGVtIEkgaGF2ZSBoZXJlIGlzIHRoYXQgaXTi gJlzIHBhc3Rpbmcgc2VtYW50aWNzIGFuZA0KIGZvcm1hdHMgb250byBhIGZpZWxkIHdoZXJlIG5v bmUgZXhpc3RlZCBiZWZvcmUsIGFuZCB0aGF04oCZcyByaWZlIGZvciBwcm9ibGVtcy4gQmV0dGVy IHRvIGhhdmUgYSBzdHJ1Y3R1cmUgdGhhdCB0YWtlcyB0aGF0IGludG8gYWNjb3VudCBmcm9tIHRo ZSBzdGFydCwgaW4gbXkgdmlldy4pPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U29sdmluZyB0 aGUgTkFTQ0FSIHByb2JsZW0gPC9iPi0gT25lIG9mIHRob3NlIGVuZHVyaW5nIHByb2JsZW1zIGlu IGlkZW50aXR5IHN5c3RlbXMsIHdoaWNoIEkgdGhpbmsgaXMgcmVhbGx5IGFib3V0IHRoZSB0aHJl ZSB3YXkgbmVnb3RpYXRpb24gZ29pbmcgb24gYmV0d2VlbiB0aGUgUlAsIHRoZSBFbmQtVXNlciBh bmQgdGhlIFByb3ZpZGVyLiBTSU9QJ3Mgc29sdXRpb24gcHVzaGVkIGZvciBtb3N0IG9mIHRoZSBw b3dlciBpbg0KIHRoaXMgZGVjaXNpb24gbWFraW5nIHByb2Nlc3MgdG8gbGllIHdpdGggdGhlIEVu ZC1Vc2VyLCBsZXR0aW5nIHRoZW0gZGVjaWRlIHdobyB0aGV5IHdhbnQgYXMgdGhlaXIgcHJvdmlk ZXIgcmF0aGVyIHRoYW4gUlAncyBwcm92aWRpbmcgYW4gZW51bWVyYXRpb24gb2Ygd2hvIHRoZXkg c3VwcG9ydCB2aWEgcHJvdmlkZXIgaWNvbnMgb24gdGhlaXIgbG9naW4gcGFnZSBhbmQgRW5kLVVz ZXJzIGhhdmluZyB0byBzZWxlY3QgZnJvbSB0aG9zZSBvcHRpb25zLg0KIEl0IGFjY29tcGxpc2hl ZCB0aGlzIHZpYSB1c2luZyBhIGN1c3RvbSBVUkwgc2NoZW1lIG9mIGA8YSBjbGFzcz0iIj5vcGVu aWQ6Ly9gPC9hPiB3aGVyZSB0aGUgRW5kLVVzZXIgd291bGQgcmVnaXN0ZXIgdGhlaXIgY2hvc2Vu IHByb3ZpZGVyIGFzIGEgcHJvdG9jb2wgaGFuZGxlciBmb3IgdGhlIGA8YSBjbGFzcz0iIj5vcGVu aWQ6Ly9gPC9hPiBzY2hlbWUuIEhvd2V2ZXIsIGFnYWluIGFzIGEgc29sdXRpb24gaXQncyBub3Qg d2l0aG91dCBpdCdzIGNoYWxsZW5nZXMsDQogbm90YWJseTsgb25seSBhIHNpbmdsZSByZWdpc3Ry YXRpb24gYXQgYSB0aW1lIGNhbiBiZSBzdXBwb3J0ZWQsIHRoZSBhY3R1YWwgaWRlbnRpdHkgb2Yg dGhlIHByb3ZpZGVyIHJlbWFpbnMgYmxpbmQgdG8gdGhlIFJQIHVudGlsIGFmdGVyIHRoZSByZXF1 ZXN0IGlzIHNlbnQgYW5kIGl0IHJlcXVpcmVzIHJlZ2lzdHJhdGlvbiBvciBzb21lIGZvcm0gb2Yg ZGVmYXVsdCBoYW5kbGluZyAoZS5nIHdoZW4gdGhlcmUgaXMgbm8gcHJvdmlkZXIgcmVnaXN0ZXJl ZCkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+SG93IEdOQVAgY2Fu IHNvbHZlIGZvciB0aGlzPzwvYj4gSSBhY3R1YWxseSBkb24ndCB0aGluayB0aGlzIGlzIGNvcmUg dG8gR05BUCwgdGhlcmUgbWF5IGJlIHNvbWUgY29uc2lkZXJhdGlvbnMgYXJvdW5kIGRpc2NvdmVy eSB0aGF0IGFyZSB3b3J0aCBwYXlpbmcgYXR0ZW50aW9uIHRvIGJ1dCBub3QgbXVjaCBpbiB0aGUg Y29yZSBwcm90b2NvbCBkZXNpZ24uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U0lPUCBkb2VzbuKAmXQgcmVhbGx5IHNvbHZlIHRo ZSBOQVNDQVIgaXNzdWUgc2luY2UgU0lPUCwgYnkgZGVzaWduLCBiZWNvbWVzIHlldCBvbmUgbW9y ZSBsb2dpbiBvcHRpb24gYW1vbmcgbWFueS4gSSB0aGluayBHTkFQIGNhbiBoZWxwIHRoaXMgYnkg ZW5hYmxpbmcgdXNlci1kaXJlY3RlZCBwcm92aWRlciBkaXNjb3ZlcnkgdG8ga2ljayBvZmYgdGhl IHByb2Nlc3MsIGJ1dCBJIGFncmVlIHRoYXQgdGhlIGNvcmUgcHJvdG9jb2wNCiBkb2VzbuKAmXQg cmVhbGx5IGhhdmUgbXVjaCB0byBzYXkgaGVyZSwgYW5kIHNob3VsZG7igJl0LjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIi PkV4cGxvcmluZyBkaWZmZXJlbnQgZGVwbG95bWVudCBtb2RlbHMgZm9yIHRoZSBwcm92aWRlcjwv Yj4gLSBUaGlzIGlzIHRoZSBtb3N0IGZyZXF1ZW50bHkgdGFsa2VkIGFib3V0IGFzcGVjdCBvZiBT SU9QIGFuZCBwZXJoYXBzIHRoZSBtb3N0IGludGVyZXN0aW5nIHRvIEdOQVAuIEkgbGlrZSB0byB0 aGluayBhYm91dCB0aGUgc2NvcGUgb2YgdGhpcyBpc3N1ZSBhcyBkZXNpZ25pbmcgdG8gYWxsb3cg Zm9yDQogZWl0aGVyIGEgcGFydGlhbGx5IG9yIGZ1bGx5IGRpc3RyaWJ1dGVkL2RlY2VudHJhbGl6 ZWQgcHJvdmlkZXIsIHJhdGhlciB0aGFuIGEgY2VudHJhbGl6ZWQgb25lIChlLmcgYW4gSFRUUCZu YnNwO2Jhc2VkIEF1dGhaIHNlcnZlcikuIEFzIHlvdSBub3RlZCB0aGlzIGRvZXMgY29tZSB3aXRo IGl0cyBjaGFsbGVuZ2VzIG1hbnkgb2Ygd2hpY2ggYXJlIHRlY2huaWNhbCBpbiBuYXR1cmUsIGku ZSBob3cgdG8gYXBwcm9wcmlhdGVseSBhZGRyZXNzIGEgZGVjZW50cmFsaXplZA0KIHByb3ZpZGVy IGFuZCB3aGF0IHByb3RvY29scyBhcmUgdXNlZCB0byBjb21tdW5pY2F0ZSB3aXRoIHRoZSBwcm92 aWRlci4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+SG93IEdOQVAg Y2FuIHNvbHZlIGZvciB0aGlzPzwvYj4gSSB0aGluayB0aGF0J3MmbmJzcDt3aGF0IG11Y2ggb2Yg dGhlIGRpc2N1c3Npb24gb24gdGhpcyB0aHJlYWQgd2lsbCBiZSBhYm91dCBhbmQgd2hldGhlciB0 aGVyZSBpcyBhIGh5YnJpZCBtb2RlbCB3aGVyZSBzb21lIHJlc3BvbnNpYmlsaXR5IGlzIHN0aWxs IGNlbnRyYWxseSBhZG1pbmlzdGVyZWQgbGlrZSB0b2tlbiBpc3N1YW5jZSwgd2hpbGUgYWxsb3dp bmcgb3RoZXIgYXNwZWN0cw0KIHRvIG9jY3VyIGluIGEgbW9yZSBkaXN0cmlidXRlZCBtYW5uZXIu IElkZWFsbHkgdGhvdWdoIEknZCBsaWtlIHRvIHNlZSBjb25zaWRlcmF0aW9uIGZvciBhIGNvbXBs ZXRlbHkgZGlzdHJpYnV0ZWQgbW9kZWwgdG9vLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkkgYWdyZWUgdGhhdCB0aGlzIHNlZW1zIHRvIGJlIHRoZSBtb3N0IGludGVyZXN0aW5nIHBs YWNlIGZvciBvdmVybGFwLiBJIGRvbuKAmXQgYWN0dWFsbHkgdGhpbmsgdGhlIOKAnGh5YnJpZOKA nSBhcHByb2FjaCBjZW50cmFsaXplcyB0aGluZ3MuIEluc3RlYWQsIHlvdSBjYW4gdGhpbmsgb2Yg dGhlIFJTIGFzIGhhdmluZyBhbiBhc3NvY2lhdGVkIEFTLCBhbmQgdGhhdCBBUyBhY2NlcHRpbmcg dXNlciBjb25zZW50IGFuZCBjbGFpbXMgYXQNCiBydW50aW1lIGZyb20gYSB2YXJpZXR5IG9mIHNv dXJjZXMgKHdhbGxldHMsIFZDcywgZXRjLikuIEluIHRoaXMgd2F5LCB3ZSBhcmVu4oCZdCB0YWxr aW5nIGFib3V0IGEgc2luZ2xlIEFTIGluIHRoZSB3b3JsZCBoYW5kbGluZyBhbGwgb2YgdGhlc2Ug cmVxdWVzdHMsIHdl4oCZcmUgdGFsa2luZyBhYm91dCBhIGRpc3RyaWJ1dGVkIG5ldHdvcmsgb2Yg QVPigJlzIGFzc29jaWF0ZWQgd2l0aCBhbiBldmVuIG1vcmUgd2lkZWx5IGRpc3RyaWJ1dGVkIHNl dCBvZiBSU+KAmXMuDQogU1NJIGFuZCBpdHMgYXNzb2NpYXRlZCB0ZWNobm9sb2dpZXMgd291bGQg aGVscCB0aGVzZSDigJxsb2NhbOKAnSBBU+KAmXMgaXNzdWUgYWNjZXNzIHRva2VucyB3aXRob3V0 IHRoZSBSTyBuZWVkaW5nIHRvIGhhdmUgYW4gYWNjb3VudCwgb3IgZXZlbiBuZWNlc3NhcmlseSBk aXJlY3RseSBpbnRlcmFjdGluZyB3aXRoIHRoZSBBUy4gVGhlcmXigJlzIGN1cnJlbnRseSBhIHRl Y2hub2xvZ3kgZ2FwIHRoZXJlLCBidXQgbXkgdGhvdWdodHMgYXJlIHRoYXQgdGhpcyBpcw0KIHdo ZXJlIHRoZSBjaGFuZ2VzIHRvIHRoZSBpbnRlcmFjdGlvbiBtb2RlcyBzZWN0aW9uIGNhbiByZWFs bHkgY29tZSB0byBwbGF5LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSB0aGluayB0aGUgbm90aW9uIG9mIGEgbm9uLUhUVFAg QVMgaXMgaW50ZXJlc3RpbmcsIGJ1dCBJ4oCZbSBub3Qgc3VyZSBpZiB0aGF04oCZcyBzb21ldGhp bmcgR05BUCBvdWdodCB0byBiZSBzb2x2aW5nIGZvci4gSSB0aGluayB0aGF0IHRoZXJl4oCZcyBh IGRlZXAgdmFsdWUgaW4gYnVpbGRpbmcgb24gdG9wIG9mIEhUVFAgZm9yIHRoZSBjb3JlIHByb3Rv Y29sLCBhbmQgbm90IGFic3RyYWN0aW5nIGF3YXkgY29uY2VwdHMgZnJvbSBpdC4NCiBPdGhlcndp c2UsIHlvdSBlbmQgdXAgcmUtaW52ZW50aW5nIGxheWVycywgYW5kIHlvdSBnZXQgc29tZXRoaW5n IGxpa2UgU09BUCBhbGwgb3ZlciBhZ2Fpbi4gOik8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwO+KAlCBKdXN0aW48L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+VGhhbmtzLDxi ciBjbGFzcz0iIj4NCjx0YWJsZSBjbGFzcz0iIiB3aWR0aD0iYXV0byIgY2VsbHNwYWNpbmc9IjAi IGNlbGxwYWRkaW5nPSIwIiBib3JkZXI9IjAiIHN0eWxlPSJmb250LWZhbWlseTpUaW1lczsgZm9u dC1zaXplOmluaGVyaXQ7IGJvcmRlcjowcHgiPg0KPHRib2R5IGNsYXNzPSIiPg0KPHRyIGNsYXNz PSIiIHN0eWxlPSIiPg0KPHRkIGNsYXNzPSIiIHdpZHRoPSIxMjUiIHZhbGlnbj0idG9wIj48YSBo cmVmPSJodHRwczovL3d3dy5nb29nbGUuY29tL3VybD9xPWh0dHBzOi8vbWF0dHIuZ2xvYmFsLyZh bXA7c291cmNlPWdtYWlsLWltYXAmYW1wO3VzdD0xNjE0Mzc5ODI4MDAwMDAwJmFtcDt1c2c9QU92 VmF3Mnc5QUwtVEwyUWxITzZSd3hxV1F5WiIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiIHN0eWxl PSJib3JkZXI6bm9uZTsgY29sb3I6cmdiKDE1LDE3MywyMjUpIj48aW1nIGFsdD0iTWF0dHIKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdl YnNpdGUiIGNsYXNzPSIiIHdpZHRoPSIxMjUiIGhlaWdodD0iMTI1IiBzdHlsZT0iaGVpZ2h0OmF1 dG8iIHNyYz0iaHR0cHM6Ly9tYXR0ci5nbG9iYWwvYXNzZXRzL2ltYWdlcy9NYXR0ckxvZ28ucG5n Ij48L2E+PC90ZD4NCjx0ZCBjbGFzcz0iIiB3aWR0aD0iMTYiPiZuYnNwOzwvdGQ+DQo8dGQgY2xh c3M9IiIgd2lkdGg9IjE1OSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJjb2xvcjpyZ2IoNTEsNDksNTAp OyBmb250LXNpemU6MTJweCI+DQo8dGFibGUgY2xhc3M9IiIgY2VsbHNwYWNpbmc9IjAiIGNlbGxw YWRkaW5nPSIwIiBib3JkZXI9IjAiIHN0eWxlPSJib3JkZXI6MHB4Ij4NCjx0Ym9keSBjbGFzcz0i Ij4NCjx0ciBjbGFzcz0iIiBzdHlsZT0iIj4NCjx0ZCBjbGFzcz0iIj48c3Ryb25nIGNsYXNzPSIi IHN0eWxlPSJmb250LXNpemU6MTJweCI+VG9iaWFzIExvb2tlcjwvc3Ryb25nPjxiciBjbGFzcz0i Ij4NCjwvdGQ+DQo8L3RyPg0KPHRyIGNsYXNzPSIiIHN0eWxlPSIiPg0KPHRkIGNsYXNzPSIiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNnB4Ij5NYXR0cjwvdGQ+DQo8L3RyPg0KPHRyIGNsYXNzPSIiIHN0 eWxlPSIiPg0KPHRkIGNsYXNzPSIiIHN0eWxlPSJsaW5lLWhlaWdodDoxNnB4OyBwYWRkaW5nLXRv cDoxMnB4Ij4rNjQgKDApIDI3IDM3OCAwNDYxPGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRv OnRvYmlhcy5sb29rZXJAbWF0dHIuZ2xvYmFsIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiIgc3R5 bGU9ImJvcmRlcjpub25lOyBjb2xvcjpyZ2IoNTEsNDksNTApIj50b2JpYXMubG9va2VyQG1hdHRy Lmdsb2JhbDwvYT48L3RkPg0KPC90cj4NCjx0ciBjbGFzcz0iIiBzdHlsZT0iIj4NCjx0ZCBjbGFz cz0iIiBzdHlsZT0iZm9udC1zaXplOjEycHg7IHBhZGRpbmctdG9wOjEycHgiPg0KPHRhYmxlIGNs YXNzPSIiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgYm9yZGVyPSIwIiBzdHlsZT0i Ym9yZGVyOjBweCI+DQo8dGJvZHkgY2xhc3M9IiI+DQo8dHIgY2xhc3M9IiIgc3R5bGU9IiI+DQo8 dGQgY2xhc3M9IiIgd2lkdGg9IjQwIj48YSBocmVmPSJodHRwczovL3d3dy5nb29nbGUuY29tL3Vy bD9xPWh0dHBzOi8vbWF0dHIuZ2xvYmFsLyZhbXA7c291cmNlPWdtYWlsLWltYXAmYW1wO3VzdD0x NjE0Mzc5ODI4MDAwMDAwJmFtcDt1c2c9QU92VmF3Mnc5QUwtVEwyUWxITzZSd3hxV1F5WiIgdGFy Z2V0PSJfYmxhbmsiIGNsYXNzPSIiIHN0eWxlPSJib3JkZXI6bm9uZTsgY29sb3I6cmdiKDUxLDQ5 LDUwKTsgbWFyZ2luLXJpZ2h0OjEycHgiPjxpbWcgYWx0PSJNYXR0ciB3ZWJzaXRlIiBjbGFzcz0i IiB3aWR0aD0iMjQiIHN0eWxlPSJib3JkZXI6MHB4OyBoZWlnaHQ6NDBweDsgd2lkdGg6MjRweCIg c3JjPSJodHRwczovL21hdHRyLmdsb2JhbC9hc3NldHMvaW1hZ2VzL3dlYnNpdGUucG5nIj48L2E+ PC90ZD4NCjx0ZCBjbGFzcz0iIiB3aWR0aD0iNDAiPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmdvb2ds ZS5jb20vdXJsP3E9aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2NvbXBhbnkvbWF0dHJnbG9iYWwm YW1wO3NvdXJjZT1nbWFpbC1pbWFwJmFtcDt1c3Q9MTYxNDM3OTgyODAwMDAwMCZhbXA7dXNnPUFP dlZhdzNsTU1xOE5CYzJTUXlkUE4yTDQ1NkEiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIiBzdHls ZT0iYm9yZGVyOm5vbmU7IGNvbG9yOnJnYig1MSw0OSw1MCk7IG1hcmdpbi1yaWdodDoxMnB4Ij48 aW1nIGFsdD0iTWF0dHIgb24KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIExpbmtlZEluIiBjbGFzcz0iIiB3aWR0aD0iMjQiIHN0eWxlPSJi b3JkZXI6MHB4OyBoZWlnaHQ6NDBweDsgd2lkdGg6MjRweCIgc3JjPSJodHRwczovL21hdHRyLmds b2JhbC9hc3NldHMvaW1hZ2VzL2xpbmtlZGluLnBuZyI+PC9hPjwvdGQ+DQo8dGQgY2xhc3M9IiIg d2lkdGg9IjQwIj48YSBocmVmPSJodHRwczovL3d3dy5nb29nbGUuY29tL3VybD9xPWh0dHBzOi8v dHdpdHRlci5jb20vbWF0dHJnbG9iYWwmYW1wO3NvdXJjZT1nbWFpbC1pbWFwJmFtcDt1c3Q9MTYx NDM3OTgyODAwMDAwMCZhbXA7dXNnPUFPdlZhdzB6ZVNMOXNuX2FrLVVPQk1xMHlQcXYiIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIiBzdHlsZT0iYm9yZGVyOm5vbmU7IGNvbG9yOnJnYig1MSw0OSw1 MCk7IG1hcmdpbi1yaWdodDoxMnB4Ij48aW1nIGFsdD0iTWF0dHIgb24KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFR3aXR0ZXIiIGNsYXNz PSIiIHdpZHRoPSIyNCIgc3R5bGU9ImJvcmRlcjowcHg7IGhlaWdodDo0MHB4OyB3aWR0aDoyNHB4 IiBzcmM9Imh0dHBzOi8vbWF0dHIuZ2xvYmFsL2Fzc2V0cy9pbWFnZXMvdHdpdHRlci5wbmciPjwv YT48L3RkPg0KPHRkIGNsYXNzPSIiIHdpZHRoPSI0MCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuZ29v Z2xlLmNvbS91cmw/cT1odHRwczovL2dpdGh1Yi5jb20vbWF0dHJnbG9iYWwmYW1wO3NvdXJjZT1n bWFpbC1pbWFwJmFtcDt1c3Q9MTYxNDM3OTgyODAwMDAwMCZhbXA7dXNnPUFPdlZhdzJELUVYS2lG VndpT1h5bm9DbllPVlEiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIiBzdHlsZT0iYm9yZGVyOm5v bmU7IGNvbG9yOnJnYig1MSw0OSw1MCk7IG1hcmdpbi1yaWdodDoxMnB4Ij48aW1nIGFsdD0iTWF0 dHIgb24KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEdpdGh1YiIgY2xhc3M9IiIgd2lkdGg9IjI0IiBzdHlsZT0iYm9yZGVyOjBweDsgaGVp Z2h0OjQwcHg7IHdpZHRoOjI0cHgiIHNyYz0iaHR0cHM6Ly9tYXR0ci5nbG9iYWwvYXNzZXRzL2lt YWdlcy9naXRodWIucG5nIj48L2E+PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwv dGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8 L3RhYmxlPg0KPGJyIGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTpUaW1lczsgZm9udC1zaXpl OmluaGVyaXQiPg0KPHNtYWxsIGNsYXNzPSIiIHN0eWxlPSIiPlRoaXMgY29tbXVuaWNhdGlvbiwg aW5jbHVkaW5nIGFueSBhdHRhY2htZW50cywgaXMgY29uZmlkZW50aWFsLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ugc2hvdWxkIG5vdCByZWFkIGl0IC0gcGxlYXNl IGNvbnRhY3QgbWUgaW1tZWRpYXRlbHksIGRlc3Ryb3kgaXQsIGFuZCBkbyBub3QgY29weSBvciB1 c2UgYW55IHBhcnQgb2YgdGhpcyBjb21tdW5pY2F0aW9uIG9yIGRpc2Nsb3NlDQogYW55dGhpbmcg YWJvdXQgaXQuIFRoYW5rIHlvdS4gUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGNvbW11bmljYXRpb24g ZG9lcyBub3QgZGVzaWduYXRlIGFuIGluZm9ybWF0aW9uIHN5c3RlbSBmb3IgdGhlIHB1cnBvc2Vz IG9mIHRoZSBFbGVjdHJvbmljIFRyYW5zYWN0aW9ucyBBY3QgMjAwMi48L3NtYWxsPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJ4X2dtYWlsX3F1b3RlIj4NCjxkaXYgZGly PSJsdHIiIGNsYXNzPSJ4X2dtYWlsX2F0dHIiPk9uIFRodSwgRmViIDE4LCAyMDIxIGF0IDk6MTkg UE0gRmFiaWVuIEltYmF1bHQgJmx0OzxhIGhyZWY9Im1haWx0bzpmYWJpZW4uaW1iYXVsdEBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5mYWJpZW4uaW1iYXVsdEBnbWFpbC5jb208 L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJ4 X2dtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4CjAuOGV4OyBib3JkZXItbGVm dC13aWR0aDoxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjpy Z2IoMjA0LDIwNCwyMDQpOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJhdXRvIiBjbGFz cz0iIj5IaSBKdXN0aW4sDQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+SSBhZ3JlZSB0aGF0IGRlZmluaW5nIEFT IHJvbGUgcHJpbWFyaWx5IGFzIGEgdG9rZW4gaXNzdWVyIGlzIGEgZnJ1aXRmdWwgaWRlYS4gU29s dmluZyB0aGlzIHByb2JsZW0gd2VsbCB3b3VsZCBhbHNvIHJlc3BvbmQgdG8gdGhlIGNoYWxsZW5n ZXMgZGlzY3Vzc2VkIHByZXZpb3VzbHkgb24gdGhlIGxpc3QuJm5ic3A7PC9kaXY+DQo8ZGl2IGRp cj0iYXV0byIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIg Y2xhc3M9IiI+Q2hlZXJzPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+RmFiaWVuJm5i c3A7PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJ4X2dt YWlsX3F1b3RlIiBkaXI9ImF1dG8iPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9InhfZ21haWxfYXR0 ciI+TGUgbWVyLiAxNyBmw6l2ci4gMjAyMSDDoCAyMzoyNywgSnVzdGluIFJpY2hlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmpy aWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IGEgw6ljcml0Jm5ic3A7OjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgY2xhc3M9InhfZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBw eCAwcHgKMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29s aWQ7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgi Pg0KPGRpdiBjbGFzcz0iIj5UaGUgbGFzdCBpbnRlcmltIGNhbGwgaGFkIGEgbG90IG9mIGRpc2N1 c3Npb24gb24gU1NJIHRlY2hub2xvZ2llcyBzdWNoIGFzIGRpZ2l0YWwgd2FsbGV0cywgYW5kIGhv dyB0aG9zZSBmaXQgd2l0aCBHTkFQLiBJIHRoaW5rIGl04oCZcyB3b3J0aCBjb250aW51aW5nIHRo YXQgY29udmVyc2F0aW9uIGhlcmUgb24gdGhlIGxpc3QuIFRoZXJlIGFyZSBhIGZldyBpc3N1ZXMg aW4gdGhlIHRyYWNrZXIgdGhhdCBnaXZlIHNvbWUgYmFja2dyb3VuZCwNCiB0b286DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRw czovL3d3dy5nb29nbGUuY29tL3VybD9xPWh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLWduYXAv Z25hcC1jb3JlLXByb3RvY29sL2lzc3Vlcy8xNzUmYW1wO3NvdXJjZT1nbWFpbC1pbWFwJmFtcDt1 c3Q9MTYxNDM3OTgyODAwMDAwMCZhbXA7dXNnPUFPdlZhdzFxbmQyRjc5em1Ra19MR3RheXNLZVAi IHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vZ2l0aHVi LmNvbS9pZXRmLXdnLWduYXAvZ25hcC1jb3JlLXByb3RvY29sL2lzc3Vlcy8xNzU8L2E+PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+VGhlcmXigJlzIGJlZW4gYSBsb3Qgb2YgaW50ZXJlc3Rpbmcgd29yayByZWNl bnRseSBpbiB0aGUgT3BlbklEIEZvdW5kYXRpb24gYXJvdW5kIHVzaW5nIHRoZSBTZWxmLWlzc3Vl ZCBPUCAoU0lPUCkgZnVuY3Rpb25hbGl0eSB0byBib290c3RyYXAgYW4gU1NJIHN0eWxlIGxvZ2lu LiBUaGlzIG1ha2VzIGV4dGVuc2l2ZSB1c2Ugb2YgdGhlIGltcGxpY2l0IGZsb3cgYW5kIGZyb250 IGNoYW5uZWwgbWVzc2FnaW5nLCBidXQgbWluaW1pemF0aW9uDQogb2YgdGhlIGZyb250IGNoYW5u ZWwgZm9yIG1lc3NhZ2UgcGFzc2luZyBpcyBhIGtleSBkZXNpZ24gdGVuZXQgb2YgR05BUCAoc28g bXVjaCBzbyB0aGF0IGl04oCZcyBpbmNsdWRlZCBpbiBvdXIgY2hhcnRlcikuIEluc3RlYWQsIEdO QVAgaGFzIGJlZW4gYnVpbHQgYXJvdW5kIGFuIGlkZWEgdGhhdCBldmVyeXRoaW5nIHN0YXJ0cyB0 aGUgc2FtZSB3YXk6IHdpdGggYW4gSFRUUCByZXF1ZXN0IHRvIHRoZSBBUy4mbmJzcDs8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBp ZGVhIG9mIGFuIG9uLWRldmljZSBBUyBoYXMgYmVlbiBicm91Z2h0IHVwIGEgbG90LCBhbmQgd2Ug bmVlZCB0byBjb25zaWRlciBpZiBhbmQgaG93IHdlIHdhbnQgdG8gZGVhbCB3aXRoIHRoZXNlIGtp bmRzIG9mIHVzZSBjYXNlcy4gVGhlIG1vc3Qgb2J2aW91cyB3YXkgdG8gYWRkcmVzcyB0aGVzZSB3 b3VsZCBiZSB0byBkbyBzb21lIGtpbmQgb2YgY2xldmVyIG9mZi1IVFRQIGhhY2sgbGlrZSBTSU9Q LCBidXQga2VlcA0KIGluIG1pbmQgdGhhdCBldmVuIFNJT1AgZ2VuZXJhbGx5IHN0YXJ0cyBvZmYg d2l0aCBhbiBIVFRQLWJhc2VkIGRpc2NvdmVyeSBjYWxsIGJ5IHRoZSBSUCB0byBtYWtlIHRoaW5n cyB3b3JrLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+TXkgcGVyc29uYWwgc3RhbmNlIGlzIHRoYXQgdG8gZG8gdGhpcywgd2UgbmVlZCB0 byByZS1ldmFsdWF0ZSBvdXIgYXNzdW1wdGlvbnMgYWJvdXQgZXhhY3RseSB3aGF0IGFuIEFTIGRv ZXMgYW5kIHdoYXQgaXQgbmVlZHMgdG8gZG8gdGhvc2UgdGhpbmdzLiBJbiBPQXV0aCAyLCBpdOKA mXMgYXNzdW1lZCB0aGF0IHRoZSBBUyBpcyB0aGUgZGV2aWNlIHRoYXTigJlzIGF1dGhlbnRpY2F0 aW5nIHRoZSB1c2VyLCBjb2xsZWN0aW5nIGNvbnNlbnQsDQogbWFuYWdpbmcgdGhlIGNsaWVudOKA mXMgcmVnaXN0cmF0aW9uLCBhbmQgY3JlYXRpbmcgYW4gYWNjZXNzIHRva2VuIGJhc2VkIG9uIHdo YXRldmVyIHNldCBvZiByaWdodHMgdGhhdCBhcmUgYXNzb2NpYXRlZCB3aXRoIGFsbCBvZiB0aG9z ZSB0aGluZ3MuIEluIFVNQSwgdGhpcyBpcyB0dXJuZWQgYXJvdW5kIGEgYml0IGJ5IGxldHRpbmcg dGhlIFJPIHByZXNlbnQgYSBidW5jaCBvZiBuZWJ1bG91cyDigJxjbGFpbXPigJ0gaW50ZXJhY3Rp dmVseSwgYnV0IHN0aWxsDQogYXQgdGhlIEFTLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2l0aCBib3RoIG9mIHRoZXNlLCBh IGtleSBhc3BlY3QgcmVtYWluczogdGhlIEFTIG5lZWRzIHRvIGdhdGhlciBuZWNlc3NhcnkgaW5m b3JtYXRpb24sIGFuZCBpc3N1ZSB0aGUgYWNjZXNzIHRva2VuIChvciBpZGVudGlmaWVycy9hc3Nl cnRpb25zKS4gQmVjYXVzZSBvZiBob3cgdGhlIHByb3RvY29sIHdvcmtzLCB0aGUgY2xpZW50IHNv ZnR3YXJlIG5vdyBoYXMgYSBiZXR0ZXIgb3Bwb3J0dW5pdHkgdG8gcHJlc2VudCBpbmZvcm1hdGlv bg0KIHRvIHRoZSBBUywgZWl0aGVyIGRpcmVjdGx5IGluIHRoZSByZXF1ZXN0IG9yIGJ5IGludHJv ZHVjaW5nIHRoZSBBUyB0byBhbm90aGVyIHNvZnR3YXJlIGNvbXBvbmVudCBkdXJpbmcgdGhlIOKA nGludGVyYWN0aW9u4oCdIHBoYXNlLiBTbywgd2hhdCBpZiB3ZSB0aGluayBvZiB0aGUgQVMgcHJp bWFyaWx5IGFzIGEg4oCcdG9rZW4gaXNzdWVy4oCdPyZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Rm9yIGV4YW1wbGUsIGlmIHRo ZSBjbGllbnQgY2FuIHByZXNlbnQgYSB2ZXJpZmlhYmxlIGNyZWRlbnRpYWwgKFZDKSB0aGF0IHJl cHJlc2VudHMgdGhlIGVuZCB1c2VyLCB0aGUgQVMgY2FuIHZhbGlkYXRlIHRoYXQgVkMgYW5kIG1h a2UgYW4gYWNjZXNzIHRva2VuIG9uIGJlaGFsZiBvZiB0aGF0IHVzZXIsIHdpdGhvdXQgaGF2aW5n IHRoZSB1c2VyIGxvZyBpbiBvciBpbnRlcmFjdCB3aXRoIHRoZSBBUyBhdCBhbGwuIFRoaXMNCiBW QyBjYW4gY29udGFpbiB3aGF0ZXZlciBhY2Nlc3MgcmlnaHRzIHRoZSB0b2tlbiBuZWVkcyB0byBy ZXByZXNlbnQsIGFuZCB0aGUgQVMgY2FuIHRyYW5zbGF0ZSB0aGF0IGludG8gYW4gYXJ0aWZhY3Qg dGhhdCB0aGUgZG93bnN0cmVhbSBSU+KAmXMgY2FuIGludGVycHJldCwgd2l0aG91dCBoYXZpbmcg dG8gc2VlIHRoZSBvcmlnaW5hbCBWQyBvciB0aGUgdXNlciBhdCBhbGwuIFRoZSBBUyBpcyBzdGls bCBIVFRQIGJhc2VkLCBidXQgYWxsIHRoZSBlc3NlbnRpYWwNCiBzZWN1cml0eSBhbmQgcmlnaHRz IGVsZW1lbnRzIGFyZSBwcm92aWRlZCBieSB0aGUgd2FsbGV0LiBJbiB0aGlzIHdheSwgd2UgY2Fu IGV4cGFuZCBvbiB0aGUgcHJpdmFjeS1wcmVzZXJ2aW5nIGFzcGVjdHMgb2YgT0F1dGggYW5kIGJy aWRnZSB0aGUgd29ybGRzIG9mIFNTSSBhbmQgd2ViIEFQSXMgd2l0aG91dCB2aW9sYXRpbmcgdGhl IGJhc2ljIG5hdHVyZSBvZiBlaXRoZXIuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Db21pbmcgZnJvbSB0aGUgT0F1dGggd29ybGQsIGl0 IGZlZWxzIHdlaXJkIHRvIGlzc3VlIHRva2VucyBsaWtlIHRoaXMsIGJ1dCB0aGVyZeKAmXMgcHJl Y2VkZW50IGZvciB0aGlzIGtpbmQgb2YgdGhpbmcuIFRvZGF5LCBhIHRoZXJlIGFyZSBhIG51bWJl ciBvZiBzZXJ2aWNlLWJhc2VkIE9BdXRoIEFTJ3MgdGhhdCBhcmUgdG9sZCB3aGF0IGNsYWltcyBu ZWVkIHRvIGdldCBwdXQgaW50byB0aGUgYWNjZXNzIHRva2VuIGJ5IHNvbWUNCiB0cnVzdGVkIGNv bXBvbmVudC4gQWxsIG9mIHRoaXMgaGFwcGVucyBvdXRzaWRlIHRoZSBPQXV0aCBwcm90b2NvbC4g SW4gR05BUCwgSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBhY2NvdW50IGZvciB0aGlzIGtpbmQg b2YgdGhpbmcgaW4gaG93IHdlIGRlZmluZSB0aGUgcHJvdG9jb2wuIFRoYXQgaXNu4oCZdCB0byBz YXkgYWxsIG9mIHRoZXNlIHBpZWNlcyBuZWVkIHRvIGJlIGRlZmluZWQgaW4gdGhlIGNvcmUsIGJ1 dCB0aGUgYmFzZSBwcm90b2NvbA0KIG91Z2h0IHRvIGJlIGFibGUgdG8gaGFuZGxlIGJlaW5nIGV4 dGVuZGVkIGluIHRoaXMgZGlyZWN0aW9uIGFzIG5lZWRlZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPknigJltIHJlYWxseSBpbnRlcmVz dGVkIHRvIGhlYXIgb3RoZXIgcGVvcGxl4oCZcyB0aG91Z2h0cyBvbiBob3cgdGhpcyBjb3VsZCBj b21lIHRvZ2V0aGVyLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+Jm5ic3A74oCUIEp1c3RpbjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCi0t IDxiciBjbGFzcz0iIj4NClRYQXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVm PSJtYWlsdG86VFhBdXRoQGlldGYub3JnIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r IiBjbGFzcz0iIj5UWEF1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuZ29vZ2xlLmNvbS91cmw/cT1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3R4YXV0aCZhbXA7c291cmNlPWdtYWlsLWltYXAmYW1wO3VzdD0xNjE0Mzc5ODI4MDAw MDAwJmFtcDt1c2c9QU92VmF3M2F2c1VHUTQ4Zm8xT1VRVjB2eXlLZCIgcmVsPSJub3JlZmVycmVy CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vcmVmZXJy ZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3R4YXV0aDwvYT48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KLS0gPGJyIGNsYXNzPSIiPg0KVFhBdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0i Ij4NCjxhIGhyZWY9Im1haWx0bzpUWEF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj5UWEF1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuZ29vZ2xlLmNvbS91cmw/cT1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3R4YXV0aCZhbXA7c291cmNlPWdtYWlsLWltYXAmYW1wO3VzdD0xNjE0Mzc5ODI4MDAwMDAwJmFt cDt1c2c9QU92VmF3M2F2c1VHUTQ4Zm8xT1VRVjB2eXlLZCIgcmVsPSJub3JlZmVycmVyIiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90eGF1dGg8L2E+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8cHJlIGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyxDb3VyaWVyLG1vbm9zcGFjZSxhcmlhbCxzYW5zLXNlcmlmOyBtYXJnaW4tdG9wOjBw eDsgbWFyZ2luLWJvdHRvbTowcHg7IHdoaXRlLXNwYWNlOnByZS13cmFwOyBiYWNrZ3JvdW5kLWNv bG9yOnJnYigyNTUsMjU1LDI1NSk7IGZvbnQtc2l6ZToxNHB4Ij5UaGlzIGNvbW11bmljYXRpb24s IGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMsIGlzIGNvbmZpZGVudGlhbC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IHNob3VsZCBub3QgcmVhZCBpdCAtIHBsZWFz ZSBjb250YWN0IG1lIGltbWVkaWF0ZWx5LCBkZXN0cm95IGl0LCBhbmQgZG8gbm90IGNvcHkgb3Ig dXNlIGFueSBwYXJ0IG9mIHRoaXMgY29tbXVuaWNhdGlvbiBvciBkaXNjbG9zZSBhbnl0aGluZyBh Ym91dCBpdC4gVGhhbmsgeW91LiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgY29tbXVuaWNhdGlvbiBk b2VzIG5vdCBkZXNpZ25hdGUgYW4gaW5mb3JtYXRpb24gc3lzdGVtIGZvciB0aGUgcHVycG9zZXMg b2YgdGhlIEVsZWN0cm9uaWMgVHJhbnNhY3Rpb25zIEFjdCAyMDAyLjwvcHJlPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KLS0gPGJyIGNsYXNz PSIiPg0KVFhBdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpU WEF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5UWEF1dGhAaWV0Zi5vcmc8 L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS91cmw/cT1o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCZhbXA7c291cmNlPWdt YWlsLWltYXAmYW1wO3VzdD0xNjE0Mzc5ODI4MDAwMDAwJmFtcDt1c2c9QU92VmF3M2F2c1VHUTQ4 Zm8xT1VRVjB2eXlLZCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8L2E+PGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8c3BhbiBjbGFzcz0iIj4tLSA8L3NwYW4+PGJy IGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+VFhBdXRoIG1haWxpbmcgbGlzdDwvc3Bhbj48YnIg Y2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj48YSBocmVmPSJtYWlsdG86VFhBdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+VFhBdXRoQGlldGYub3JnPC9hPjwvc3Bhbj48YnIg Y2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3d3dy5nb29nbGUuY29t L3VybD9xPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoJmFtcDtz b3VyY2U9Z21haWwtaW1hcCZhbXA7dXN0PTE2MTQzNzk4MjgwMDAwMDAmYW1wO3VzZz1BT3ZWYXcz YXZzVUdRNDhmbzFPVVFWMHZ5eUtkIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93 d3cuZ29vZ2xlLmNvbS91cmw/cT1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3R4YXV0aCZhbXA7c291cmNlPWdtYWlsLWltYXAmYW1wO3VzdD0xNjE0Mzc5ODI4MDAwMDAwJmFt cDt1c2c9QU92VmF3M2F2c1VHUTQ4Zm8xT1VRVjB2eXlLZDwvYT48L3NwYW4+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJy Pg0KPGZpZWxkc2V0IGNsYXNzPSJ4X21pbWVBdHRhY2htZW50SGVhZGVyIj48L2ZpZWxkc2V0PiA8 L2Jsb2NrcXVvdGU+DQo8cD48YnI+DQo8L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FR2P281MB013815C2EA1CC7FEBAB88FD08D9F9FR2P281MB0138DEUP_-- From nobody Wed Feb 24 09:47:45 2021 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 A66F53A18CC for ; Wed, 24 Feb 2021 09:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 iQcj2TQm7--Z for ; Wed, 24 Feb 2021 09:47:30 -0800 (PST) Received: from mail-ua1-f50.google.com (mail-ua1-f50.google.com [209.85.222.50]) (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 301AA3A18B8 for ; Wed, 24 Feb 2021 09:47:30 -0800 (PST) Received: by mail-ua1-f50.google.com with SMTP id o31so1000720uae.2 for ; Wed, 24 Feb 2021 09:47:30 -0800 (PST) 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=Vy2cepDV5cDHnrh0xhW//4YrDkbknIPvSAWHyW02vq4=; b=Y8bb58IqDKfTyot6hlrWTcagMoOlClE0GJu3vD/dFsgwkPdNroY+9mc38mx1QWsutD jv+C8RQ8iwawmmAOM9m88hr6hBEidATugaysueS69v5aC5znUpYJ1Wylok2UKdIdDHyq L1sa3yQnSLt4Dj3wz54nesZiYsfk+nvVp2yGM9b3s1qw3gDCLIPasQu125fsrYbJOhX8 +DBcfQ6vRtgGLnwQrqxCRc31LUQjAgGAI5VR8jSHShuLrphIKn0sl7RSq+vWOxYDjEY+ DjsHbI+84u9BF4UELldxigA9IWvF9tbjg3J/SIQBHi2BiYq1T2u/Gp/zCRHP6fIqQY5Y 8akw== X-Gm-Message-State: AOAM5317PbFHQlJMwJ4QSLjUIH6q4rx0oVTen9szPZDPU2uKUJV0ul/y P9+Gp3nqwpF3DtztrFEeakknz1Kqr5zB7WjWtVE= X-Google-Smtp-Source: ABdhPJxJBIUsX53Q677KqA6pP6OW+G4XY+VJD0qrGzoIcwmqt9oqnvN+NUcIuVPTK4UkYxh1rInBD5MYIwKOxyafVnQ= X-Received: by 2002:a9f:280a:: with SMTP id c10mr22124721uac.7.1614188848650; Wed, 24 Feb 2021 09:47:28 -0800 (PST) MIME-Version: 1.0 References: <4EAA60A4-4800-400F-A70A-F7B7F1A6CB0A@mit.edu> <73cd4e8b-c843-ab87-c640-eea763b6002a@free.fr> In-Reply-To: From: Adrian Gropper Date: Wed, 24 Feb 2021 12:47:17 -0500 Message-ID: To: Francis Pouatcha Cc: Denis , Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="000000000000ec9e6605bc18a06a" Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 17:47:43 -0000 --000000000000ec9e6605bc18a06a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It might help the GNAP scoping discussion relative to SSI if we consider two separate domains: - *Registration:* The relationship between the RO and the RS prior to any GNAP Client entering the picture, and - *Authorization:* The interaction protocols between the user agents of end users and servers Fact: Only two SSI standards (VC and DID) are established enough for us to reference in GNAP and they are both merely data models, not protocols. Neither of these data models is particularly concerned with delegation protocols although there is going to be some impact from things like multi-signature schemes and filtering of capabilities. IMHO, GNAP as a delegation protocol standard cannot presume the success or applicability of any SSI inspired protocols, including DIDcomm or Confidential Storage, that are still trying to figure out their relationship to HTTP. Also, IMHO, SSI is not synonymous with protocols that presume a Holder as a mandated intermediary store for any attribute that moves between an issuer and a verifier. There are many, maybe most, use cases where SSI would be better served by control of the attribute over actual possession of the attribute. Adrian On Wed, Feb 24, 2021 at 12:09 PM Francis Pouatcha wrote: > Integrating GNAP and SSI requires a lot of fundamentals: > > > - AS had their essence in the fact that human held devices were not > able to produce authorization sharable to client and RS > - If the human held device can do the work, it is natural the momentum > will shift in that direction. This is what is happening with SSI. > - Sharing all views of Adrian mention in this thread(no need to > repeat). > - But repeating the keyword: ZTA. Keeping custodian, server centered > architectures under control is getting tougher as time goes by. > > In GNAP initial discussion, we walked through a lot of abstract diagram, > that could have allowed production of authorization and authentication > material (token) by human held devices. The intention was inspired from S= SI > discussions. > > IF > Justin is asking to reconsider an integration of SSI, > > THEN > we need to review the abstract protocol flows: > > - roles > - entities > - relationships > > We will have to start by taking the http protocol constraint out of the > charter. > > BTW > > - I agree with Justin: "The RS decides on how to consume a presented > token." > - I agree with Denis: "AS plays no role and shall have no influence on > the RS decision on how to consume a token." > > > THEN > We must start by sharping the meaning of an AS (in the context of GNAP). > Discussion might lead to a retirement of this term. As mortals might have= a > hard time considering a user held device a server. > > END IF > > > Nevertheless, the transition from (http)-AS based token production to use= r > device-based token production will need some 10+ years to complete. Still= a > lot of challenges around how to protect keys held on user devices against > damage, loss of device, malware, ransomware, social engineered attack. > > Can GNAP be the main vehicle for this transition? Maybe. Despite the (too= ) > strong reliance on the OAuth legacy (even if GNAP does not promise backwa= rd > compatibility to OAuth), an *embedded* interaction that allows the client > to carry the user device produced token to the resource server might pave > way for this transition. I campaigned for consideration of an *embedded > interaction* in the initial conversation. I am not sure this was taken > into account. Still must find time to review the current draft. > > > /Francis > > > ------------------------------ > *From:* TXAuth on behalf of Denis < > denis.ietf@free.fr> > *Sent:* Tuesday, February 23, 2021 12:51 PM > *To:* Justin Richer ; txauth gnap > *Subject:* Re: [GNAP] Integrating a GNAP AS with wallets and SSI > > Hi Justin, > > See my comments between the lines. > > An important aspect in the discussion here, that I agree with, is that th= e > RS needs to be able to decide *which AS it talks to*. > > While I would agree with such a sentence in the OAuth WG, I don't believ= e > that this sentence is applicable in general in the context of GNAP. > A RS does not need to "talk to" any AS. A RS decides which AS(s) it trust= s > to issue access tokens *that contains some set of privileges*. > > But inherent in that is that it=E2=80=99s not the user=E2=80=99s decision= , or the AS=E2=80=99s > decision, it=E2=80=99s the RS=E2=80=99s decision who it will trust to get= tokens from. > > A RS does not necessarily need to trust all the access tokens issued by a > given AS, but only access tokens from a given AS that contain > *a given set of privileges*. > > And no matter what our philosophy, at the end of the day the RS will > always have the choice of whether to trust an inbound request. > > Not exactly: the RS will apply the rules given by the RO. > > Which is why, to me, this really brings us to the question of what an AS > provides. The AS gives the RS a token that the RS decides to trust, > and that the RS can understand (either directly with something like JWT o= r > indirectly with something like introspection). > But the AS also needs to decide what to put INTO that token. As a > consequence, the AS can get that information from any number of places. > The information could be provided in a trusted way by the end user to the > AS =E2=80=94 but this does NOT necessarily mean that the AS belongs > to the user or is under their control. > > Basically, I think we=E2=80=99re trying to hard to map the OAuth general-= concept > of the RO having an account at the AS and logging in to it before > authorizing the request. > I think that the call for =E2=80=9Cevery user to have their own AS=E2=80= =9D is such a huge > non-starter in so many domains that it hampers the solution space if that= =E2=80=99s > what we presume. > It=E2=80=99s up to the RS to decide who it trusts, not the end user and n= ot the > RO. > > I think we should ALLOW it, and we can be clearer in GNAP that that=E2=80= =99s one > possible model, but not the only one, and not even the general one. > The AS manages all of the information and interconnections needed to > create an access token that the RS will accept, and it is in charge of > signaling to the RS what that token=E2=80=99s good for. > > I disagree: the AS is NOT in charge of signaling to the RS what that > token=E2=80=99s good for. It is up to the RS to decide which privileges i= t will > accept > among all the privileges included into an access token. > > However, if the AS can learn through some other means that a specific > identified user has consented and provided appropriate information in a > trusted way, > then THAT information can be baked into the token by the AS. =E2=80=94 im= portantly,* > in a way that the RS=E2=80=99s the AS protects can understand*. > > I disagree: Trust relationships are not bilateral but only unilateral. An > AS does not need to have any specific prior relationship with a given RS. > It is up to the RS(s) to decide which AS*(s)* it trust(s) *and for which > privileges*. > > This last bit is where general *opacity of tokens* is important here. > There=E2=80=99s a natural security boundary that arises from this model. = What I=E2=80=99m > proposing here is just that we=E2=80=99re more explicit about what can be= put INTO > that boundary. That=E2=80=99s where I=E2=80=99m seeing a lot of this inno= vation in the SSI > space fitting. You=E2=80=99re not coming up with some universal access to= ken that > the RS will accept, but you=E2=80=99re able to provide universal claims a= nd > artifacts that an AS can process and *translate into a token the RS will > accept and do the right thing with*. > > Your argumentation about token opacity is making the assumption that the > AS and the RS need to have a prior relationship before any access can tak= e > place. > While this was valid with OAuth, this is no more valid in the context of > GNAP. The client should be able to inform the AS about the access token > format(s) acceptable to the RS. > Then the client may indicate to the AS these acceptable formats. If the R= S > and the AS have an access token format in common, then the process may > continue. > > When only attributes (i.e. not rights) are being requested to an AS by th= e > client, the client does not need to disclose the identity of the RS to th= e > AS, > which has the major advantage to prevent the AS to act as Big Brother. > > *Note*: this does not preclude the use of rights, in particular in > the context of a single organization or enterprise. > > Denis > > > =E2=80=94 Justin > > On Feb 21, 2021, at 9:40 AM, Adrian Gropper > wrote: > > Hi Torsten, > > Thank you for raising all of these excellent points. I hope we can all > answer them and maybe even add a section to the wiki. I'll start... > > You're right that OAuth deployments almost exclusively put the AS and RS > in the same domain. If OAuth were adequate to today's needs we probably > would not be here doing GNAP. Since OAuth, we have increasing privacy > concerns and security disasters. GDPR, for example, separates the role of= a > data controller from a data processor and treats them as separate legal > entities. To oversimplify GDPR, the data processor is spared privacy > responsibility and cost. > > You are also right to mention open banking as a use-case. Open banking ha= s > not adopted UMA 2.0 (on which I have worked for almost a decade) which is > based on OAuth. PSD2 and similar regulations do not tie the AS and RS to > the same security domain but they presume a narrow federation of licensed > (and regulated) ASs as payment processors for subjects to choose among. > This centralization to regulated fiduciaries is a privacy trade-off that > makes sense in banking. The fiduciary can be bonded so they can refund th= e > money to the subject in case of a security breach. This privacy-security > tradeoff does not make sense in healthcare and other domains where the > consequences of a breach are not easily reversed. > > This thread is about aligning GNAP and SSI. SSI does not abide > centralization, censorship, or surveillance. If GNAP makes any assumption= s > that result in either a tight coupling between AS and RS (surveillance) o= r > even a federated fiduciary (centralization) we will lose out on the > benefits of progress in digital identity that is now driving a lot of > public-sector initiatives and starting to bleed over into private sector > practices. Zero Trust Architecture is an example and OAuth is not well > suited for ZTA. > > As you said, "technically, the respective AS and RSs set up a trust > relationship and agreed on ways to share authorization and user data in > order [to] enable secure API access." This is where GNAP operates and we > need to avoid _any_ restrictions on either the AS or the RS being > self-sovereign. Examples of a self-sovereign RS could be a personal data > store or an encrypted data vault like the ones we work on in W3C/DIF. Any > AS can be self-sovereign if the subject controls all of the policies and > these policies are not shared, in the same way a private key is never not > shared. > > Continuing your quote: > > I read your ideas regarding self-sovereign ASs with great interest and go= t > some observations/questions: > - A personal AS could certainly control access to a person=E2=80=98s reso= urces. I > assume the person=E2=80=98s RSs would only accept access tokens signed by= the RO. > Am I right? > > Yes, and. There is debate in various SSI WGs whether a RS such as an > Encrypted Data Vault should respond to capabilities or tokens. Either way= , > the RO is in control of the signature but a personal AS is a delegate of > the RO (either directly or via a mobile user agent). With capabilities su= ch > as ZCAP-LD or biscuits, the token signature allows for filtered delegatio= n. > > - Do you envision this AS to be able to control access to any kind of RS? > How is the AS supposed to know what authorization data this RS needs in > order to perform access control decisions? What data will be exchanged? > > Yes. The whole point, as far as I'm concerned, is to design human centere= d > standards. This is how W3C and IETF are different. Other SDOs tend to be > operated for institutional benefit. A person-centered AS must work across > institutional domains. > > This, as you point out, brings up the problem of scope. Ontologies and > data models are, justifiably, domain-specific. I, for example, work aroun= d > the HL7 data model standards and APIs like FHIR that are controlled by > healthcare business interests. It's unreasonable to expect a general > solution to the data model problem, although folks of the Linked Data > persuasion might disagree. > > Every RS gets to decide what data models and ontologies it supports. Thes= e > decisions are public and sometimes standardized for the benefit of the > clients. A person's AS must read and maybe understand the RS data model i= n > order to issue tokens just like the client needs to do in order to make a > request to the AS. In our HIE of One Trustee project, we allow the > self-sovereign subject to inherit AS policies from self-sovereign > communities they choose and then modify the policies if they want. In thi= s > way, communities compete for members on the basis of policy bundles the > same way churches compete for congregants. > > - How would this person delegate access to her resources to someone else? > > There are two "persons" to consider. The RO delegates to an RQ. But the > RQ, in real life, is part of a team and often delegates to associates. Wi= th > or without capabilities, GNAP needs to deal with this reality that RO and > RQ user agents may be different from the client that actually presents a > token to the RS. Some of this difference between user agents and clients = we > may be able to keep out of band. > > - Are you aware of deployments implementing this philosophy? > > Other than our HIE of One demonstration project in healthcare, no. We > started HIE of One before SSI in order to drive the transition from UMA t= o > UMA 2.0 and inform various healthcare regulatory priorities. We then jump= ed > on SSI immediately and added it to the UMA 2 AS we call Trustee. Now we a= re > trying to align SSI and GNAP in order to enable human-centered protocols > and zero-trust architecture. > > > - What are the implications in terms of user experience? > > Right now, the human-centered user experience assumes a secure element an= d > web browser as user agents on a mobile device. Neither of these is readil= y > accessible as a server nor are they designed to accept code plug-ins that > represent the policies of an AS. One major exception is people adding > advertising and surveillance blockers like EFF Privacy Badger to their > browser. > > The user experience implications of having SSI data model standards and > GNAP protocol standards is that today's password managers (I have 250 RS > relationships in mine) will evolve to also control an AS agent. Just like= I > might register a W3C DID with an RS instead of an email address, my polic= y > manager might display to me the token policies that will be applied by my > AS to the personal data I can control at that RS. > > In some cases, my AS will allow me to modify those policies just like the > obnoxious cookie policy settings do today. The BIG difference with GNAP i= s > that I choose my AS separately from the RS so the dark patterns associate= d > with today's cookie policies experience are no longer possible. GNAP mean= s > the RS exposes an API rather than a UI. > > I've gone on far too long to address the issue of the AS as an identity > provider. It's fair to think of it that way. As it turns out, in the SSI > Secure Data Storage WG, we are debating the difference between an Encrypt= ed > Data Vault and an Identity Hub. As far as I'm concerned, the Identity Hub > is mostly a GNAP AS. Join us on Thursdays at 4 PM ET > https://lists.identity.foundation/g/sds-wg/wiki/Home > > Adrian > > > > On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > > > Am 19.02.2021 um 23:50 schrieb Adrian Gropper : > > =EF=BB=BF > I agree with the first two of Justin's responses but not the last one. > > It's confusing to think that there are more RS than AS. > > > the OAuth deployments I=E2=80=98m aware of typically have much more RSs t= han ASs. > Why? Because AS and a set of RSs belong to the same security domain (e.g.= a > certain business) and it=E2=80=99s the AS=E2=80=99s responsibility to ens= ure secure and > convenient access to the APIs provided by this RSs. For example: there is= a > AS controlling access to a cloud, streaming, and messaging services of th= e > same business. In case of open banking, the bank=E2=80=98s AS is (on beha= lf of the > user) authorizing access to APIs for account information as well as payme= nt > initiation and potentially other services. > > Technically, the respective AS and RSs set up a trust relationship and > agreed on ways to share authorization and user data in order enable secur= e > API access. > > I read your ideas regarding self-sovereign ASs with great interest and go= t > some observations/questions: > - A personal AS could certainly control access to a person=E2=80=98s reso= urces. I > assume the person=E2=80=98s RSs would only accept access tokens signed by= the RO. > Am I right? > - Do you envision this AS to be able to control access to any kind of RS? > How is the AS supposed to know what authorization data this RS needs in > order to perform access control decisions? What data will be exchanged? > - How would this person delegate access to her resources to someone else? > - Are you aware of deployments implementing this philosophy? > - What are the implications in terms of user experience? > > In my experience coupling between AS and RS is very tight. I have a hard > time to see how self-sovereign ASs would work. It feels like such an AS i= n > the end is an identity provider of some sort, which brings me to what > Justin proposed. I would assume using SSI credentials to authenticate > towards ASs is feasible and might have value but I=E2=80=98m skeptical ab= out the AS > part. > > best regards, > Torsten. > > From a human-centered (and hopefully IETF) perspective, each person might > control or specify a different AS for each of their personas or for each > child or incompetent delegate of them as guardian. We're familiar with > separate gmail addresses for each persona. > > ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial > bitcoin wallet), or brokers (as in data brokers and surveillance > capitalism). Any RS that is willing to have a recurring relationship with= a > persona could accept a GNAP AS endpoint instead of an email address. This > is easiest using HTTP, but GNAP need not exclude other RS / AS APIs and > transports. Designing around the uncensored specification of one's AS as = a > human right would greatly simplify many aspects of GNAP adoption. > > That said, GNAP should not ignore the RS business or > jurisdictional reasons to limit the authority of the AS. UMA 2.0 spent > years dancing around this issue with ideas like "cascading" AS and variou= s > centralized or federated AS concepts. My conclusion is that any RS can > always do whatever it wants and there's not much the authorization protoc= ol > can help with other than specifying a notification endpoint so that an RS > can warn (and seek confirmation) or log various exceptions. This turns ou= t > to be, after a year of testimony, the regulation that applies to HIPAA RS > APIs in the US. For this reason GNAP might include a notification protoco= l > in the AS specification, or not. > > I propose that embracing a self-sovereign agent is key to harmonizing the > SSI and GNAP standards. > > Adrian > > On Fri, Feb 19, 2021 at 2:30 PM Justin Richer wrote: > > Tobias, thanks for the great observations. Some reactions inline below. > > On Feb 18, 2021, at 7:59 PM, Tobias Looker > wrote: > > Justin, > > I think this is a great and timely conversation to be having given the > current interest around SSI and efforts like SIOP, I have been doing quit= e > a bit of work in this space as of recent, so thought I'd add a few of the > observations that I've made. > > In my opinion SIOP was really a bucket for solving quite a few different > problems, not just one. In particular I think its intent was to solve 3 > major ones: > > 1. Enabling portable identities > 2. Solving the NASCAR problem > 3. Exploring different deployment models for the provider > > To drill down briefly on these, note much of my terminology is OpenID > based due to SIOPs origin > > *Enabling portable identities *- In general today in the case of OpenID, > the end-users identity as understood by a relying party is scoped within > the domain of the provider. Which means if that provider goes out of > business or for whatever reason decides to no longer offer the same > identity services to the End-User, their identity is essentially gone. > Whilst there has been some interesting related work from groups like MODR= NA > on solutions to combat this like 'Account Porting', they often assume the > old provider remains online and willing to facilitate in the account > porting process so that the End-User can migrate to a new provider. SIOP > actually elected to do something different here by using cryptography, > instead of the End-User identifier being something like a GUID asserted > within the domain of the provider, SIOP defined this instead as a public > key fingerprint associated to a private key that's assumed to be under th= e > control of the user. In doing so the identity itself becomes portable > between providers by transferring the associated private key. Now this > approach does have drawbacks and arguably encourages what many would refe= r > to as bad cryptographic practise by not allowing any way to do key > rotation, however the idea was there. > > *How GNAP can solve for this?* By having flexibility around how the > resource owner / End-User is referred to by the Authorization server (e.g > allow the identifier to be something like a public key or a resolvable > identifier to public keys such as a DID) > > > I personally think that GNAP should be a flexible :carrier: of identifier= s > and other bits of identity information. This is the main reason we went > with the Subject Identifiers draft from SECEVENT: it=E2=80=99s set up to = talk about > a variety of different kinds of identifiers, all of them asserted in the > context of the AS. If there=E2=80=99s a definition for a DID URL or a JWK= in the > sub_ids object structure, GNAP would be able to just use it directly > alongside every other format. I haven=E2=80=99t seen those proposed yet, = but it > would be easy to do and, in my mind, would be a better solution than the > portable identifiers proposal that was recently brought up in the FAPI > working group in OIDF. (A side note, but the main problem I have here is > that it=E2=80=99s pasting semantics and formats onto a field where none e= xisted > before, and that=E2=80=99s rife for problems. Better to have a structure = that takes > that into account from the start, in my view.) > > > *Solving the NASCAR problem *- One of those enduring problems in identity > systems, which I think is really about the three way negotiation going on > between the RP, the End-User and the Provider. SIOP's solution pushed for > most of the power in this decision making process to lie with the End-Use= r, > letting them decide who they want as their provider rather than RP's > providing an enumeration of who they support via provider icons on their > login page and End-Users having to select from those options. It > accomplished this via using a custom URL scheme of `openid://` where the > End-User would register their chosen provider as a protocol handler for t= he > `openid://` scheme. However, again as a solution it's not without it's > challenges, notably; only a single registration at a time can be supporte= d, > the actual identity of the provider remains blind to the RP until after t= he > request is sent and it requires registration or some form of default > handling (e.g when there is no provider registered). > > *How GNAP can solve for this?* I actually don't think this is core to > GNAP, there may be some considerations around discovery that are worth > paying attention to but not much in the core protocol design. > > > SIOP doesn=E2=80=99t really solve the NASCAR issue since SIOP, by design,= becomes > yet one more login option among many. I think GNAP can help this by > enabling user-directed provider discovery to kick off the process, but I > agree that the core protocol doesn=E2=80=99t really have much to say here= , and > shouldn=E2=80=99t. > > *Exploring different deployment models for the provider* - This is the > most frequently talked about aspect of SIOP and perhaps the most > interesting to GNAP. I like to think about the scope of this issue as > designing to allow for either a partially or fully > distributed/decentralized provider, rather than a centralized one (e.g an > HTTP based AuthZ server). As you noted this does come with its challenges > many of which are technical in nature, i.e how to appropriately address a > decentralized provider and what protocols are used to communicate with th= e > provider. > > *How GNAP can solve for this?* I think that's what much of the discussion > on this thread will be about and whether there is a hybrid model where so= me > responsibility is still centrally administered like token issuance, while > allowing other aspects to occur in a more distributed manner. Ideally > though I'd like to see consideration for a completely distributed model t= oo. > > > I agree that this seems to be the most interesting place for overlap. I > don=E2=80=99t actually think the =E2=80=9Chybrid=E2=80=9D approach centra= lizes things. Instead, you > can think of the RS as having an associated AS, and that AS accepting use= r > consent and claims at runtime from a variety of sources (wallets, VCs, > etc.). In this way, we aren=E2=80=99t talking about a single AS in the wo= rld > handling all of these requests, we=E2=80=99re talking about a distributed= network > of AS=E2=80=99s associated with an even more widely distributed set of RS= =E2=80=99s. SSI > and its associated technologies would help these =E2=80=9Clocal=E2=80=9D = AS=E2=80=99s issue access > tokens without the RO needing to have an account, or even necessarily > directly interacting with the AS. There=E2=80=99s currently a technology = gap there, > but my thoughts are that this is where the changes to the interaction mod= es > section can really come to play. > > I think the notion of a non-HTTP AS is interesting, but I=E2=80=99m not s= ure if > that=E2=80=99s something GNAP ought to be solving for. I think that there= =E2=80=99s a deep > value in building on top of HTTP for the core protocol, and not abstracti= ng > away concepts from it. Otherwise, you end up re-inventing layers, and you > get something like SOAP all over again. :) > > =E2=80=94 Justin > > > Thanks, > [image: Mattr website] > > > *Tobias Looker* > Mattr > +64 (0) 27 378 0461 > tobias.looker@mattr.global > [image: Mattr website] > [image: > Mattr on LinkedIn] > [image: > Mattr on Twitter] > [imag= e: > Mattr on Github] > > This communication, including any attachments, is confidential. If you ar= e > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > > On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault > wrote: > > Hi Justin, > > I agree that defining AS role primarily as a token issuer is a fruitful > idea. Solving this problem well would also respond to the challenges > discussed previously on the list. > > Cheers > Fabien > > > Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer = a =C3=A9crit : > > The last interim call had a lot of discussion on SSI technologies such as > digital wallets, and how those fit with GNAP. I think it=E2=80=99s worth = continuing > that conversation here on the list. There are a few issues in the tracker > that give some background, too: > > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 > > > There=E2=80=99s been a lot of interesting work recently in the OpenID Fou= ndation > around using the Self-issued OP (SIOP) functionality to bootstrap an SSI > style login. This makes extensive use of the implicit flow and front > channel messaging, but minimization of the front channel for message > passing is a key design tenet of GNAP (so much so that it=E2=80=99s inclu= ded in our > charter). Instead, GNAP has been built around an idea that everything > starts the same way: with an HTTP request to the AS. > > The idea of an on-device AS has been brought up a lot, and we need to > consider if and how we want to deal with these kinds of use cases. The mo= st > obvious way to address these would be to do some kind of clever off-HTTP > hack like SIOP, but keep in mind that even SIOP generally starts off with > an HTTP-based discovery call by the RP to make things work. > > My personal stance is that to do this, we need to re-evaluate our > assumptions about exactly what an AS does and what it needs to do those > things. In OAuth 2, it=E2=80=99s assumed that the AS is the device that= =E2=80=99s > authenticating the user, collecting consent, managing the client=E2=80=99= s > registration, and creating an access token based on whatever set of right= s > that are associated with all of those things. In UMA, this is turned arou= nd > a bit by letting the RO present a bunch of nebulous =E2=80=9Cclaims=E2=80= =9D interactively, > but still at the AS. > > With both of these, a key aspect remains: the AS needs to gather necessar= y > information, and issue the access token (or identifiers/assertions). > Because of how the protocol works, the client software now has a better > opportunity to present information to the AS, either directly in the > request or by introducing the AS to another software component during the > =E2=80=9Cinteraction=E2=80=9D phase. So, what if we think of the AS prima= rily as a =E2=80=9Ctoken > issuer=E2=80=9D? > > For example, if the client can present a verifiable credential (VC) that > represents the end user, the AS can validate that VC and make an access > token on behalf of that user, without having the user log in or interact > with the AS at all. This VC can contain whatever access rights the token > needs to represent, and the AS can translate that into an artifact that t= he > downstream RS=E2=80=99s can interpret, without having to see the original= VC or the > user at all. The AS is still HTTP based, but all the essential security a= nd > rights elements are provided by the wallet. In this way, we can expand on > the privacy-preserving aspects of OAuth and bridge the worlds of SSI and > web APIs without violating the basic nature of either. > > Coming from the OAuth world, it feels weird to issue tokens like this, bu= t > there=E2=80=99s precedent for this kind of thing. Today, a there are a nu= mber of > service-based OAuth AS's that are told what claims need to get put into t= he > access token by some trusted component. All of this happens outside the > OAuth protocol. In GNAP, I think it makes sense to account for this kind = of > thing in how we define the protocol. That isn=E2=80=99t to say all of the= se pieces > need to be defined in the core, but the base protocol ought to be able to > handle being extended in this direction as needed. > > I=E2=80=99m really interested to hear other people=E2=80=99s thoughts on = how this could > come together. > > =E2=80=94 Justin > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > This communication, including any attachments, is confidential. If you ar= e not the intended recipient, you should not read it - please contact me im= mediately, destroy it, and do not copy or use any part of this communicatio= n or disclose anything about it. Thank you. Please note that this communica= tion does not designate an information system for the purposes of the Elect= ronic Transactions Act 2002. > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > > https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txau= th&source=3Dgmail-imap&ust=3D1614379828000000&usg=3DAOvVaw3avsUGQ48fo1OUQV0= vyyKd > > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000ec9e6605bc18a06a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    It might help the GNAP scoping discussion relative to SSI = if we consider two separate domains:=C2=A0
    - Registration: The r= elationship between the RO and the RS prior to any GNAP Client entering the= picture, and
    - Authorization: The interaction protocols b= etween the user agents of end users and servers

    Fa= ct: Only two SSI standards (VC and DID) are established enough for us to re= ference in GNAP and they are both merely data models, not protocols. Neithe= r of these data models is particularly=C2=A0concerned with delegation proto= cols although there is going to be some impact from things like multi-signa= ture schemes and filtering of capabilities.

    IMHO, = GNAP as a delegation protocol=C2=A0standard cannot presume the success or a= pplicability of any SSI inspired protocols, including DIDcomm or Confidenti= al Storage, that are still trying to figure out their relationship to HTTP.= =C2=A0

    Also, IMHO, SSI is not synonymous with prot= ocols that presume a Holder as a mandated intermediary store for any attrib= ute that moves between an issuer and a verifier. There are many, maybe most= , use cases where SSI would be better served by control of the attribute ov= er actual possession of the attribute.

    Adrian



    On Wed, Feb 24, 2021 at 12:09 PM Francis Pou= atcha <fpo=3D40adorsys.de= @dmarc.ietf.org> wrote:
    Integrating GNAP and SSI requires a lot of fundamentals:

    • AS had their essence in the fact that human held devices were not= able to produce authorization sharable to client and RS
    • If the human held device can do the work, it is natural the momentum wil= l shift in that direction. This is what is happening with SSI.
      • <= li>Sharing all views of Adrian mention in this thread(no need to repe= at).=C2=A0
    • But repeating the keyword: ZTA. Keeping cus= todian, server centered architectures under control is getting tougher as t= ime goes by.
    In GNAP initial discussion, we walked through a lot of abstract diagram, th= at could have allowed production of authorization and authentication materi= al (token) by human held devices. The intention was inspired from SSI discu= ssions.=C2=A0

    IF
    =C2=A0 Justin is asking to reconsider an integration of SSI,

    THEN
    we need to review the abstract protocol flows:
    • roles
    • entities
    • relation= ships
    We will have to start by taking the http protocol constraint out of the cha= rter.

    BTW
    • I agree with Justin: "The RS decides on how to consume a presented= token."
    • I agree with Denis: "AS plays no role and shall = have no influence on the RS decision on how to consume a token."
      • <= /ul>

    THEN
    We must start by sharping the meaning of an AS (in the context of GNAP). Di= scussion might lead to a retirement of this term. As mortals might have a h= ard time considering a user held device a server.

    END IF


    Nevertheless, the transition from (http)-AS based token production to user = device-based token production will need some 10+ years to complete. Still a= lot of challenges around how to protect keys held on user devices against = damage, loss of device, malware, ransomware, social engineered attack.

    Can GNAP be the main vehicle for this transition? Maybe. Despite the (too) = strong reliance on the OAuth legacy (even if GNAP does not promise backward= compatibility to OAuth), an embedded interaction that allows the client to carry the user device= produced token to the resource server might pave way for this transition. = I campaigned for consideration of an embedded interaction in the initial conversation. I am not sure this= was taken into account. Still must find time to review the current draft.<= /div>


    /Francis


    From= : TXAuth <txauth-bounces@ietf.org> on behalf of Denis <denis.ietf@free.fr>
    Sent: Tuesday, February 23, 2021 12:51 PM
    To: Justin Richer <jricher@mit.edu>; txauth gnap <txauth@ietf.org>
    Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI
    =C2=A0
    Hi=C2=A0 Justin,

    See my comments between the lines.
    An important aspect in the discussion here, that = I agree with, is that the RS needs to be able to decide which AS it talks to.

    =C2=A0While I would agree with such a sentence i= n the OAuth WG, I don't believe that this sentence is applicable in gen= eral in the context of GNAP.
    A RS does not need to "talk to" any AS. A RS decides which AS(s) = it trusts to issue access tokens that contains some set of privileges.

    But inherent in that is that it=E2=80=99s not the= user=E2=80=99s decision, or the AS=E2=80=99s decision, it=E2=80=99s the RS= =E2=80=99s decision who it will trust to get tokens from.

    A RS does not necessarily need to trust all the = access tokens issued by a given AS, but only access tokens from a given AS = that contain
    a given set of privileges.

    And no matter what our philosophy, at the end of = the day the RS will always have the choice of whether to trust an inbound r= equest.

    Not exactly: the RS will apply the rules given b= y the RO.

    Which is why, to me, this really brings us to the question of what an = AS provides. The AS gives the RS a token that the RS decides to trust,
    and that the RS can understand (either directly with something like JWT or = indirectly with something like introspection).
    But the AS also needs to decide what to put INTO that token. As a consequen= ce, the AS can get that information from any number of places.
    The information could be provided in a trusted way by the end user to the A= S =E2=80=94 but this does NOT necessarily mean that the AS belongs
    to the user or is under their control.=C2=A0

    Basically, I think we=E2=80=99re trying to hard to map the OAuth gener= al-concept of the RO having an account at the AS and logging in to it befor= e authorizing the request.
    I think that the call for =E2=80=9Cevery user to have their own AS=E2=80=9D= is such a huge non-starter in so many domains that it hampers the solution= space if that=E2=80=99s what we presume.
    It=E2=80=99s up to the RS to decide who it trusts, not the end user and not= the RO.=C2=A0

    I think we should ALLOW it, and we can be clearer in GNAP that that=E2= =80=99s one possible model, but not the only one, and not even the general = one.
    The AS manages all of the information and interconnections needed to create= an access token that the RS will accept, and it is in charge of signaling = to the RS what that token=E2=80=99s good for.

    I disagree: the AS is NOT in charge of signaling= to the RS what that token=E2=80=99s good for. It is up to the RS to decide= which privileges it will accept
    among all the privileges included into an access token.

    However, if the AS can learn through some other means that a specific = identified user has consented and provided appropriate information in a tru= sted way,
    then THAT information can be baked into the token by the AS. =E2=80=94 impo= rtantly, in a way that the RS=E2=80=99s the AS protects can understan= d.

    I disagree: Trust relationships are not bilatera= l but only unilateral. An AS does not need to have any specific prior relat= ionship with a given RS.
    It is up to the RS(s) to decide which AS(s) it trust(s) an= d for which privileges.

    This last bit is where general opacity of tokens is impo= rtant here. There=E2=80=99s a natural security boundary that arises from th= is model. What I=E2=80=99m proposing here is just that we=E2=80=99re more e= xplicit about what can be put INTO that boundary. That=E2=80=99s where I=E2=80=99m seeing a lot of this innovation in the SS= I space fitting. You=E2=80=99re not coming up with some universal access to= ken that the RS will accept, but you=E2=80=99re able to provide universal c= laims and artifacts that an AS can process and translate into a token the RS will accept and do the right thing with= .

    Your argumentation about token opacity is making= the assumption that the AS and the RS need to have a prior relationship be= fore any access can take place.
    While this was valid with OAuth, this is no more valid in the context of GN= AP.=C2=A0 The client should be able to inform the AS about the access token= format(s) acceptable to the RS.
    Then the client may indicate to the AS these acceptable formats. If the RS = and the AS have an access token format in common, then the process may cont= inue.

    When only attributes (i.e. not rights) are being= requested to an AS by the client, the client does not need to disclose the= identity of the RS to the AS,
    which has the major advantage to prevent the AS to act as Big Brother.

    =C2=A0=C2=A0=C2=A0 Note: this does not pr= eclude the use of rights, in particular in the context of a single organiza= tion or enterprise.

    Denis


    =C2=A0=E2=80=94 Justin

    On Feb 21, 2021, at 9:40 AM, Adrian Gropper <agropper@healthurl.com> wrote:=

    Hi Torsten,

    Thank you for raising all of these excellent points. I hope we can all= answer them and maybe even add a section to the wiki. I'll start...

    You're right that OAuth deployments almost exclusively put the AS = and RS in the same domain. If OAuth were adequate to today's needs we p= robably would not be here doing GNAP. Since OAuth, we have increasing priva= cy concerns and security disasters. GDPR, for example, separates the role of a data controller from a data pro= cessor and treats them as separate legal entities. To oversimplify GDPR, th= e data processor is spared privacy responsibility and cost.

    You are also right to mention open banking as a use-case. Open banking= has not adopted UMA 2.0 (on which I have worked for almost a decade) which= is based on OAuth. PSD2 and similar regulations do not tie the AS and RS t= o the same security domain but they presume a narrow federation of licensed (and regulated) ASs as pa= yment processors for subjects to choose among. This centralization to regul= ated fiduciaries is a privacy trade-off that makes sense in banking. The fi= duciary can be bonded so they can refund the money to the subject in case of a security breach. This privacy= -security tradeoff does not make sense in healthcare and other domains wher= e the consequences of a breach are not easily reversed.

    This thread is about aligning GNAP and SSI. SSI does not abide central= ization, censorship, or surveillance. If GNAP makes any assumptions that re= sult in either a tight coupling between AS and RS (surveillance) or even a = federated fiduciary (centralization) we will lose out on the benefits of progress in digital identity that is n= ow driving a lot of public-sector initiatives and starting to bleed over in= to private sector practices. Zero Trust Architecture is an example and OAut= h is not well suited for ZTA.

    As you said, "technically, the respective AS and RSs set up a tru= st relationship and agreed on ways to share authorization and user data in = order [to] enable secure API access." This is where GNAP operates and = we need to avoid _any_ restrictions on either the AS or the RS being self-sovereign. Examples of a self-sovere= ign RS could be a personal data store or an encrypted data vault like the o= nes we work on in W3C/DIF. Any AS can be self-sovereign if the subject cont= rols all of the policies and these policies are not shared, in the same way a private key is never not shared= .=C2=A0

    Continuing your quote:
    I read your ideas regarding self-sovereign ASs with great interest and got = some observations/questions:
    - A personal AS could certainly control access to a person=E2=80=98s resour= ces. I assume the person=E2=80=98s RSs would only accept access tokens sign= ed by the RO. Am I right?
    Yes, and. There is debate in various SSI WGs whether a RS such as an E= ncrypted Data Vault should respond to capabilities or tokens. Either way, t= he RO is in control of the signature but a personal AS is a delegate of the= RO (either directly or via a mobile user agent). With capabilities=C2=A0such as ZCAP-LD or biscui= ts, the token signature=C2=A0allows for filtered delegation.

    - Do you envision this AS to be able to control access to any kind of RS? H= ow is the AS supposed to know what authorization data this RS needs in orde= r to perform access control decisions? What data will be exchanged?
    Yes. The whole point, as far as I'm concerned, is to design human = centered standards. This is how W3C and IETF are different. Other SDOs tend= to be operated for institutional benefit. A person-centered AS must work a= cross institutional domains.=C2=A0

    This, as you point out, brings up the problem of scope. Ontologies and= data models are, justifiably, domain-specific. I, for example, work around= the HL7 data model standards and APIs like FHIR that are controlled by hea= lthcare business interests. It's unreasonable to expect a general solution to the data model probl= em, although folks of the Linked Data persuasion might disagree.

    Every RS gets to decide what data models and ontologies it supports. T= hese decisions are public and sometimes standardized for the benefit of the= clients. A person's AS must read and maybe understand the RS data mode= l in order to issue tokens just like the client needs to do in order to make a request to the AS. In = our HIE of One Trustee project, we allow the self-sovereign subject to inhe= rit AS policies from self-sovereign communities they choose and then modify= the policies if they want. In this way, communities compete for members on the basis of policy bundles the sa= me way churches compete for congregants.

    - How would this person delegate access to her resources to someone else?
    There are two "persons" to consider. The RO delegates to an = RQ. But the RQ, in real life, is part of a team and often delegates to asso= ciates. With or without capabilities, GNAP needs to deal with this reality = that RO and RQ user agents may be different from the client that actually presents a token to the=C2=A0RS. S= ome of this difference between user agents and clients we may be able to ke= ep out of band.

    - Are you aware of deployments implementing this philosophy?
    Other than our HIE of One demonstration project in healthcare, no. We = started HIE of One before SSI in order to drive the transition from UMA to = UMA 2.0 and inform various healthcare regulatory=C2=A0priorities. We then j= umped on SSI immediately and added it to the UMA 2 AS we call Trustee. Now we are trying to align SSI a= nd GNAP in order to enable human-centered protocols and zero-trust architec= ture.=C2=A0
    =C2=A0
    - What are the implications in terms of user experience?
    Right now, the human-centered user experience assumes a secure element= and web browser as user agents on a mobile device. Neither of these is rea= dily accessible=C2=A0as a server nor are they designed to accept code plug-= ins that represent the policies of an AS. One major exception is people adding advertising and surveillanc= e blockers like EFF Privacy Badger to their browser.=C2=A0

    The user experience implications of having SSI data model standards an= d GNAP protocol standards is that today's password managers (I have 250= RS relationships in mine) will evolve to also control an AS agent. Just li= ke I might register a W3C DID with an RS instead of an email address, my policy manager might display to= me the token policies that will be applied by my AS to the personal data I= can control at that RS.=C2=A0

    In some cases, my AS will allow me to modify those policies just like = the obnoxious cookie policy settings do today. The BIG difference with GNAP= is that I choose my AS separately from the RS so the dark patterns associa= ted with today's cookie policies experience are no longer possible. GNAP means the RS exposes an A= PI rather than a UI.

    I've gone on far too long to address the issue of the AS as an ide= ntity provider. It's fair to think of it that way. As it turns out, in = the SSI Secure Data Storage WG, we are debating the difference between an E= ncrypted Data Vault and an Identity Hub. As far as I'm concerned, the Identity Hub is mostly a GNAP AS. Jo= in us on Thursdays at 4 PM ET=C2=A0https://lists.identity.foundatio= n/g/sds-wg/wiki/Home=C2=A0

    Adrian



    On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt <torsten@lodderst= edt.net> wrote:


    Am 19.02.2021 um 23:50 schrieb Adrian Gropper <= ;agropper@healt= hurl.com>:

    =EF=BB=BF
    I agree with the=C2=A0first=C2=A0two of Justin's respo= nses but not the last one.

    It's confusing to think that there are more RS than AS.

    the OAuth deployments I=E2=80=98m aware of typically have much more RS= s than ASs. Why? Because AS and a set of RSs belong to the same security do= main (e.g. a certain business) and it=E2=80=99s the AS=E2=80=99s responsibi= lity to ensure secure and convenient access to the APIs provided by this RSs. For example: there is a AS controlling acce= ss to a cloud, streaming, and messaging services of the same business. In c= ase of open banking, the bank=E2=80=98s AS is (on behalf of the user) autho= rizing access to APIs for account information as well as payment initiation and potentially other services.=C2=A0

    Technically, the respective AS and RSs set up a trust relationship and= agreed on ways to share authorization and user data in order enable secure= API access.

    I read your ideas regarding self-sovereign ASs with great interest and= got some observations/questions:
    - A personal AS could certainly control access to a person=E2=80=98s r= esources. I assume the person=E2=80=98s RSs would only accept access tokens= signed by the RO. Am I right?
    - Do you envision this AS to be able to control access to any kind of = RS? How is the AS supposed to know what authorization data this RS needs in= order to perform access control decisions? What data will be exchanged?
    - How would this person delegate access to her resources to someone el= se?
    - Are you aware of deployments implementing this philosophy?
    - What are the implications in terms of user experience?

    In my experience coupling between AS and RS is very tight. I have a ha= rd time to see how self-sovereign ASs would work. It feels like such an AS = in the end is an identity provider of some sort, which brings me to what Ju= stin proposed. I would assume using SSI credentials to authenticate towards ASs is feasible and m= ight have value but I=E2=80=98m skeptical about the AS part.

    best regards,
    Torsten.

    From a human-centered (and hopefully IETF) perspective, each person mi= ght control or specify a different AS for each of their personas or for eac= h child or incompetent delegate of them as guardian. We're familiar wit= h separate gmail addresses for each persona.

    ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial b= itcoin wallet), or brokers (as in data brokers and surveillance capitalism)= . Any RS that is willing to have a recurring relationship with a persona co= uld accept a GNAP AS endpoint instead of an email address. This is easiest using HTTP, but GNAP need not= exclude other RS / AS APIs and transports. Designing around the uncensored= specification=C2=A0of one's AS as a human right would greatly simplify= many aspects of GNAP adoption.

    That said, GNAP should not ignore the RS business or jurisdictional=C2= =A0reasons to limit the authority of the AS. UMA 2.0 spent years dancing ar= ound this issue with ideas like "cascading" AS and various centra= lized or federated AS concepts. My conclusion is that any RS can always do whatever it wants and there's not much th= e authorization protocol can help with other than specifying a notification= endpoint so that an RS can warn (and seek confirmation) or log various exc= eptions. This turns out to be, after a year of testimony, the regulation that applies to HIPAA RS APIs in the U= S. For this reason GNAP might include a notification protocol in the AS spe= cification, or not.

    I propose that embracing a self-sovereign agent is key to harmonizing = the SSI and GNAP standards.

    Adrian

    On Fri, Feb 19, 2021 at 2:30 PM Justin Richer <jricher@mit.edu> wrote= :
    Tobias, th= anks for the great observations. Some reactions inline below.

    On Feb 18, 2021, at 7:59 PM, Tobias Looker <tobias.looker@mattr.global>= wrote:

    Justin,

    I think this is a great and timely conversation to be having given the curr= ent interest around SSI and efforts like SIOP, I have been doing quite a bi= t of work in this space as of recent, so thought I'd add a few of the o= bservations that I've made.

    In my opinion SIOP was really a bucket for solving quite a few different pr= oblems, not just one. In particular I think its intent was to solve 3 major= ones:

    1. Enabling portable identities
    2. Solving the NASCAR problem
    3. Exploring different deployment models for the provider

    To drill down briefly on these, note much of my terminology is OpenID based= due to SIOPs origin=C2=A0

    Enabling portable identities - In general today in the case of OpenI= D, the end-users identity as understood by a relying party is scoped within= the domain of the provider. Which means if that provider goes out of busin= ess or for whatever reason decides to no longer offer the same identity services to the End-User, the= ir identity is essentially gone. Whilst there has been some interesting rel= ated work from groups like MODRNA on solutions to combat this like 'Acc= ount Porting', they often assume the old provider remains online and willing to facilitate in the account porti= ng process so that the End-User can migrate to a new provider. SIOP actuall= y elected to do something different here by using cryptography, instead of = the End-User identifier being something like a GUID asserted within the domain of the provider, SIOP defined this = instead as a public key fingerprint associated to a private key that's = assumed to be under the control of the user. In doing so the identity itsel= f becomes portable between providers by transferring the associated private key. Now this approach does have dr= awbacks and arguably encourages what many would refer to as bad cryptograph= ic practise by not allowing any way to do key rotation, however the idea wa= s there.=C2=A0

    How GNAP can solve for this? By having flexibility around how t= he resource owner / End-User is referred to by the Authorization server (e.= g allow the identifier to be something like a public key or a resolvable id= entifier to public keys such as a DID)

    I personally think that GNAP should be a flexible :carrier: of identif= iers and other bits of identity information. This is the main reason we wen= t with the Subject Identifiers draft from SECEVENT: it=E2=80=99s set up to = talk about a variety of different kinds of identifiers, all of them asserted in the context of the AS. If th= ere=E2=80=99s a definition for a DID URL or a JWK in the sub_ids object str= ucture, GNAP would be able to just use it directly alongside every other fo= rmat. I haven=E2=80=99t seen those proposed yet, but it would be easy to do and, in my mind, would be a better solution tha= n the portable identifiers proposal that was recently brought up in the FAP= I working group in OIDF. (A side note, but the main problem I have here is = that it=E2=80=99s pasting semantics and formats onto a field where none existed before, and that=E2=80=99s rife fo= r problems. Better to have a structure that takes that into account from th= e start, in my view.)


    Solving the NASCAR problem - One of those enduring problems in ident= ity systems, which I think is really about the three way negotiation going = on between the RP, the End-User and the Provider. SIOP's solution pushe= d for most of the power in this decision making process to lie with the End-User, letting them decide= who they want as their provider rather than RP's providing an enumerat= ion of who they support via provider icons on their login page and End-User= s having to select from those options. It accomplished this via using a custom URL scheme of `openid://` w= here the End-User would register their chosen provider as a protocol handle= r for the `openid://` scheme. However, again as a solution it's = not without it's challenges, notably; only a single registration at a time can be supported, the actual= identity of the provider remains blind to the RP until after the request i= s sent and it requires registration or some form of default handling (e.g w= hen there is no provider registered).

    How GNAP can solve for this? I actually don't think this is core= to GNAP, there may be some considerations around discovery that are worth = paying attention to but not much in the core protocol design.


    SIOP doesn=E2=80=99t really solve the NASCAR issue since SIOP, by desi= gn, becomes yet one more login option among many. I think GNAP can help thi= s by enabling user-directed provider discovery to kick off the process, but= I agree that the core protocol doesn=E2=80=99t really have much to say here, and shouldn=E2=80=99t.

    Exploring different deployment models for the provider - This i= s the most frequently talked about aspect of SIOP and perhaps the most inte= resting to GNAP. I like to think about the scope of this issue as designing= to allow for either a partially or fully distributed/decentralized provider, rather tha= n a centralized one (e.g an HTTP=C2=A0based AuthZ server). As you noted thi= s does come with its challenges many of which are technical in nature, i.e = how to appropriately address a decentralized provider and what protocols are used to communicate with the provider.
    How GNAP can solve for this? I think that's=C2=A0what much of th= e discussion on this thread will be about and whether there is a hybrid mod= el where some responsibility is still centrally administered like token iss= uance, while allowing other aspects to occur in a more distributed manner. Ideally though I'd like to see = consideration for a completely distributed model too.

    I agree that this seems to be the most interesting place for overlap. = I don=E2=80=99t actually think the =E2=80=9Chybrid=E2=80=9D approach centra= lizes things. Instead, you can think of the RS as having an associated AS, = and that AS accepting user consent and claims at runtime from a variety of sources (wallets, VCs, etc.). In this way, we ar= en=E2=80=99t talking about a single AS in the world handling all of these r= equests, we=E2=80=99re talking about a distributed network of AS=E2=80=99s = associated with an even more widely distributed set of RS=E2=80=99s. SSI and its associated technologies would help these =E2=80=9Clocal=E2=80= =9D AS=E2=80=99s issue access tokens without the RO needing to have an acco= unt, or even necessarily directly interacting with the AS. There=E2=80=99s = currently a technology gap there, but my thoughts are that this is where the changes to the interaction modes section can really come to play= .=C2=A0

    I think the notion of a non-HTTP AS is interesting, but I=E2=80=99m no= t sure if that=E2=80=99s something GNAP ought to be solving for. I think th= at there=E2=80=99s a deep value in building on top of HTTP for the core pro= tocol, and not abstracting away concepts from it. Otherwise, you end up re-inventing layers, and you get something like SOAP= all over again. :)

    =C2=A0=E2=80=94 Justin


    Thanks,
    3D"Mattr =C2=A0
    Tobias Looker
    Mattr
    +64 (0) 27 378 0461
    tobias.looker@mattr.global
    3D"Mattr 3D"Mattr 3D"Mattr 3D"Mattr

    This communication, including any attachments, is confidential. If y= ou are not the intended recipient, you should not read it - please contact = me immediately, destroy it, and do not copy or use any part of this communi= cation or disclose anything about it. Thank you. Please note that this communication does not= designate an information system for the purposes of the Electronic Transac= tions Act 2002.


    On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault <fabien.imbault@gmail= .com> wrote:
    Hi Justin,

    I agree that defining AS role primarily as a token issuer= is a fruitful idea. Solving this problem well would also respond to the ch= allenges discussed previously on the list.=C2=A0

    Cheers
    Fabien=C2=A0


    Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer <= ;jricher@mit.edu&g= t; a =C3=A9crit=C2=A0:
    The last interim call had a lot of discussion on SSI technologies such= as digital wallets, and how those fit with GNAP. I think it=E2=80=99s wort= h continuing that conversation here on the list. There are a few issues in = the tracker that give some background, too:


    There=E2=80=99s been a lot of interesting work recently in the OpenID = Foundation around using the Self-issued OP (SIOP) functionality to bootstra= p an SSI style login. This makes extensive use of the implicit flow and fro= nt channel messaging, but minimization of the front channel for message passing is a key design tenet of GNAP (so= much so that it=E2=80=99s included in our charter). Instead, GNAP has been= built around an idea that everything starts the same way: with an HTTP req= uest to the AS.=C2=A0

    The idea of an on-device AS has been brought up a lot, and we need to = consider if and how we want to deal with these kinds of use cases. The most= obvious way to address these would be to do some kind of clever off-HTTP h= ack like SIOP, but keep in mind that even SIOP generally starts off with an HTTP-based discovery c= all by the RP to make things work.

    My personal stance is that to do this, we need to re-evaluate our assu= mptions about exactly what an AS does and what it needs to do those things.= In OAuth 2, it=E2=80=99s assumed that the AS is the device that=E2=80=99s = authenticating the user, collecting consent, managing the client=E2=80=99s registration, and creating an access token b= ased on whatever set of rights that are associated with all of those things= . In UMA, this is turned around a bit by letting the RO present a bunch of = nebulous =E2=80=9Cclaims=E2=80=9D interactively, but still at the AS.=C2=A0

    With both of these, a key aspect remains: the AS needs to gather neces= sary information, and issue the access token (or identifiers/assertions). B= ecause of how the protocol works, the client software now has a better oppo= rtunity to present information to the AS, either directly in the request or by introducing the AS to anot= her software component during the =E2=80=9Cinteraction=E2=80=9D phase. So, = what if we think of the AS primarily as a =E2=80=9Ctoken issuer=E2=80=9D?= =C2=A0

    For example, if the client can present a verifiable credential (VC) th= at represents the end user, the AS can validate that VC and make an access = token on behalf of that user, without having the user log in or interact wi= th the AS at all. This VC can contain whatever access rights the token needs to represent, and th= e AS can translate that into an artifact that the downstream RS=E2=80=99s c= an interpret, without having to see the original VC or the user at all. The= AS is still HTTP based, but all the essential security and rights elements are provided by the wallet. In this way, we c= an expand on the privacy-preserving aspects of OAuth and bridge the worlds = of SSI and web APIs without violating the basic nature of either.

    Coming from the OAuth world, it feels weird to issue tokens like this,= but there=E2=80=99s precedent for this kind of thing. Today, a there are a= number of service-based OAuth AS's that are told what claims need to g= et put into the access token by some trusted component. All of this happens outside the OAuth protocol. In GNAP= , I think it makes sense to account for this kind of thing in how we define= the protocol. That isn=E2=80=99t to say all of these pieces need to be def= ined in the core, but the base protocol ought to be able to handle being extended in this direction as needed.

    I=E2=80=99m really interested to hear other people=E2=80=99s thoughts = on how this could come together.

    =C2=A0=E2=80=94 Justin
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org https://ww= w.ietf.org/mailman/listinfo/txauth

    This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.

    --
    TXAuth mailing list
    TXAuth@ietf.org https://ww= w.ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org<= /a>
    https://www.google.com/= url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&source=3Dgmail-ima= p&ust=3D1614379828000000&usg=3DAOvVaw3avsUGQ48fo1OUQV0vyyKd



    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000ec9e6605bc18a06a-- From nobody Wed Feb 24 10:58:21 2021 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 971D43A19C0 for ; Wed, 24 Feb 2021 10:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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 ZMsCOQIu_QvV for ; Wed, 24 Feb 2021 10:58:11 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349973A1A0C for ; Wed, 24 Feb 2021 10:58:09 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11OIw2ou001224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Feb 2021 13:58:02 -0500 From: Justin Richer Message-Id: <34DD2820-06F8-4226-A987-DF6F1105B87D@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_0D9660AF-142C-4D26-9F72-7DF5F7AFFBA6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 24 Feb 2021 13:58:01 -0500 In-Reply-To: Cc: Francis Pouatcha , Denis , txauth gnap To: Adrian Gropper References: <4EAA60A4-4800-400F-A70A-F7B7F1A6CB0A@mit.edu> <73cd4e8b-c843-ab87-c640-eea763b6002a@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 18:58:19 -0000 --Apple-Mail=_0D9660AF-142C-4D26-9F72-7DF5F7AFFBA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 to this. In my opinion, building on anything other than HTTP right = now is speculation, at best. And building an abstraction from = zero-to-one concrete manifestations is a recipe for disaster. Once a = second thing comes along, you inevitably realize that you put the = abstraction points in the wrong place and have in fact baked in a lot of = assumptions about your base case into what was supposed to be an = abstraction layer.=20 Instead, if there=E2=80=99s a desire to build out GNAP on top of other = protocols, then it should be :translated: to those protocols. This = happened with OAuth being built on top of COAP in ACE, without OAuth = defining an abstraction layer ahead of time. And I=E2=80=99ll wager that = if we had defined such a layer, it would not have considered things like = the multi-tiered client structures that are in ACE, or the key = distribution challenges in the IoT environment. Abstractions can come = after the fact to aid future translations, but translation is nearly = always more practical.=20 But my point in starting this thread is that I think we can set up = appropriate extension points for novel elements without throwing out the = entire base protocol, or creating something overly abstract. So I think = we can keep the =E2=80=9CAS=E2=80=9D component and the central = HTTP-based protocol but have places where these other elements, like SSI = wallets, can come in. I think we need to get away from the false = conclusion that the SSI wallet has to :be: the AS. Instead, I think the = SSI wallet can feed information into an AS in order for the AS to do its = job. =E2=80=94 Justin > On Feb 24, 2021, at 12:47 PM, Adrian Gropper = wrote: >=20 > It might help the GNAP scoping discussion relative to SSI if we = consider two separate domains:=20 > - Registration: The relationship between the RO and the RS prior to = any GNAP Client entering the picture, and > - Authorization: The interaction protocols between the user agents of = end users and servers >=20 > Fact: Only two SSI standards (VC and DID) are established enough for = us to reference in GNAP and they are both merely data models, not = protocols. Neither of these data models is particularly concerned with = delegation protocols although there is going to be some impact from = things like multi-signature schemes and filtering of capabilities. >=20 > IMHO, GNAP as a delegation protocol standard cannot presume the = success or applicability of any SSI inspired protocols, including = DIDcomm or Confidential Storage, that are still trying to figure out = their relationship to HTTP.=20 >=20 > Also, IMHO, SSI is not synonymous with protocols that presume a Holder = as a mandated intermediary store for any attribute that moves between an = issuer and a verifier. There are many, maybe most, use cases where SSI = would be better served by control of the attribute over actual = possession of the attribute. >=20 > Adrian >=20 >=20 >=20 > On Wed, Feb 24, 2021 at 12:09 PM Francis Pouatcha = > = wrote: > Integrating GNAP and SSI requires a lot of fundamentals: >=20 > AS had their essence in the fact that human held devices were not able = to produce authorization sharable to client and RS > If the human held device can do the work, it is natural the momentum = will shift in that direction. This is what is happening with SSI. > Sharing all views of Adrian mention in this thread(no need to repeat).=20= > But repeating the keyword: ZTA. Keeping custodian, server centered = architectures under control is getting tougher as time goes by. > In GNAP initial discussion, we walked through a lot of abstract = diagram, that could have allowed production of authorization and = authentication material (token) by human held devices. The intention was = inspired from SSI discussions.=20 >=20 > IF > Justin is asking to reconsider an integration of SSI, >=20 > THEN > we need to review the abstract protocol flows: > roles > entities > relationships > We will have to start by taking the http protocol constraint out of = the charter. >=20 > BTW > I agree with Justin: "The RS decides on how to consume a presented = token." > I agree with Denis: "AS plays no role and shall have no influence on = the RS decision on how to consume a token." >=20 > THEN > We must start by sharping the meaning of an AS (in the context of = GNAP). Discussion might lead to a retirement of this term. As mortals = might have a hard time considering a user held device a server. >=20 > END IF >=20 >=20 > Nevertheless, the transition from (http)-AS based token production to = user device-based token production will need some 10+ years to complete. = Still a lot of challenges around how to protect keys held on user = devices against damage, loss of device, malware, ransomware, social = engineered attack. >=20 > Can GNAP be the main vehicle for this transition? Maybe. Despite the = (too) strong reliance on the OAuth legacy (even if GNAP does not promise = backward compatibility to OAuth), an embedded interaction that allows = the client to carry the user device produced token to the resource = server might pave way for this transition. I campaigned for = consideration of an embedded interaction in the initial conversation. I = am not sure this was taken into account. Still must find time to review = the current draft. >=20 >=20 > /Francis >=20 >=20 > From: TXAuth > on behalf of Denis > > Sent: Tuesday, February 23, 2021 12:51 PM > To: Justin Richer >; txauth = gnap > > Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI > =20 > Hi Justin, >=20 > See my comments between the lines. >> An important aspect in the discussion here, that I agree with, is = that the RS needs to be able to decide which AS it talks to. > While I would agree with such a sentence in the OAuth WG, I don't = believe that this sentence is applicable in general in the context of = GNAP. > A RS does not need to "talk to" any AS. A RS decides which AS(s) it = trusts to issue access tokens that contains some set of privileges. >=20 >> But inherent in that is that it=E2=80=99s not the user=E2=80=99s = decision, or the AS=E2=80=99s decision, it=E2=80=99s the RS=E2=80=99s = decision who it will trust to get tokens from.=20 > A RS does not necessarily need to trust all the access tokens issued = by a given AS, but only access tokens from a given AS that contain=20 > a given set of privileges.=20 >=20 >> And no matter what our philosophy, at the end of the day the RS will = always have the choice of whether to trust an inbound request. > Not exactly: the RS will apply the rules given by the RO. >=20 >> Which is why, to me, this really brings us to the question of what an = AS provides. The AS gives the RS a token that the RS decides to trust,=20= >> and that the RS can understand (either directly with something like = JWT or indirectly with something like introspection).=20 >> But the AS also needs to decide what to put INTO that token. As a = consequence, the AS can get that information from any number of places. >> The information could be provided in a trusted way by the end user to = the AS =E2=80=94 but this does NOT necessarily mean that the AS belongs=20= >> to the user or is under their control.=20 >>=20 >> Basically, I think we=E2=80=99re trying to hard to map the OAuth = general-concept of the RO having an account at the AS and logging in to = it before authorizing the request.=20 >> I think that the call for =E2=80=9Cevery user to have their own AS=E2=80= =9D is such a huge non-starter in so many domains that it hampers the = solution space if that=E2=80=99s what we presume.=20 >> It=E2=80=99s up to the RS to decide who it trusts, not the end user = and not the RO.=20 >>=20 >> I think we should ALLOW it, and we can be clearer in GNAP that = that=E2=80=99s one possible model, but not the only one, and not even = the general one.=20 >> The AS manages all of the information and interconnections needed to = create an access token that the RS will accept, and it is in charge of = signaling to the RS what that token=E2=80=99s good for.=20 > I disagree: the AS is NOT in charge of signaling to the RS what that = token=E2=80=99s good for. It is up to the RS to decide which privileges = it will accept=20 > among all the privileges included into an access token. >=20 >> However, if the AS can learn through some other means that a specific = identified user has consented and provided appropriate information in a = trusted way,=20 >> then THAT information can be baked into the token by the AS. =E2=80=94 = importantly, in a way that the RS=E2=80=99s the AS protects can = understand.=20 > I disagree: Trust relationships are not bilateral but only unilateral. = An AS does not need to have any specific prior relationship with a given = RS.=20 > It is up to the RS(s) to decide which AS(s) it trust(s) and for which = privileges. >=20 >> This last bit is where general opacity of tokens is important here. = There=E2=80=99s a natural security boundary that arises from this model. = What I=E2=80=99m proposing here is just that we=E2=80=99re more explicit = about what can be put INTO that boundary. That=E2=80=99s where I=E2=80=99m= seeing a lot of this innovation in the SSI space fitting. You=E2=80=99re = not coming up with some universal access token that the RS will accept, = but you=E2=80=99re able to provide universal claims and artifacts that = an AS can process and translate into a token the RS will accept and do = the right thing with. > Your argumentation about token opacity is making the assumption that = the AS and the RS need to have a prior relationship before any access = can take place. > While this was valid with OAuth, this is no more valid in the context = of GNAP. The client should be able to inform the AS about the access = token format(s) acceptable to the RS.=20 > Then the client may indicate to the AS these acceptable formats. If = the RS and the AS have an access token format in common, then the = process may continue.=20 >=20 > When only attributes (i.e. not rights) are being requested to an AS by = the client, the client does not need to disclose the identity of the RS = to the AS,=20 > which has the major advantage to prevent the AS to act as Big Brother. >=20 > Note: this does not preclude the use of rights, in particular in = the context of a single organization or enterprise. >=20 > Denis >=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Feb 21, 2021, at 9:40 AM, Adrian Gropper > wrote: >>>=20 >>> Hi Torsten, >>>=20 >>> Thank you for raising all of these excellent points. I hope we can = all answer them and maybe even add a section to the wiki. I'll start... >>>=20 >>> You're right that OAuth deployments almost exclusively put the AS = and RS in the same domain. If OAuth were adequate to today's needs we = probably would not be here doing GNAP. Since OAuth, we have increasing = privacy concerns and security disasters. GDPR, for example, separates = the role of a data controller from a data processor and treats them as = separate legal entities. To oversimplify GDPR, the data processor is = spared privacy responsibility and cost. >>>=20 >>> You are also right to mention open banking as a use-case. Open = banking has not adopted UMA 2.0 (on which I have worked for almost a = decade) which is based on OAuth. PSD2 and similar regulations do not tie = the AS and RS to the same security domain but they presume a narrow = federation of licensed (and regulated) ASs as payment processors for = subjects to choose among. This centralization to regulated fiduciaries = is a privacy trade-off that makes sense in banking. The fiduciary can be = bonded so they can refund the money to the subject in case of a security = breach. This privacy-security tradeoff does not make sense in healthcare = and other domains where the consequences of a breach are not easily = reversed. >>>=20 >>> This thread is about aligning GNAP and SSI. SSI does not abide = centralization, censorship, or surveillance. If GNAP makes any = assumptions that result in either a tight coupling between AS and RS = (surveillance) or even a federated fiduciary (centralization) we will = lose out on the benefits of progress in digital identity that is now = driving a lot of public-sector initiatives and starting to bleed over = into private sector practices. Zero Trust Architecture is an example and = OAuth is not well suited for ZTA. >>>=20 >>> As you said, "technically, the respective AS and RSs set up a trust = relationship and agreed on ways to share authorization and user data in = order [to] enable secure API access." This is where GNAP operates and we = need to avoid _any_ restrictions on either the AS or the RS being = self-sovereign. Examples of a self-sovereign RS could be a personal data = store or an encrypted data vault like the ones we work on in W3C/DIF. = Any AS can be self-sovereign if the subject controls all of the policies = and these policies are not shared, in the same way a private key is = never not shared.=20 >>>=20 >>> Continuing your quote: >>> I read your ideas regarding self-sovereign ASs with great interest = and got some observations/questions: >>> - A personal AS could certainly control access to a person=E2=80=98s = resources. I assume the person=E2=80=98s RSs would only accept access = tokens signed by the RO. Am I right? >>> Yes, and. There is debate in various SSI WGs whether a RS such as an = Encrypted Data Vault should respond to capabilities or tokens. Either = way, the RO is in control of the signature but a personal AS is a = delegate of the RO (either directly or via a mobile user agent). With = capabilities such as ZCAP-LD or biscuits, the token signature allows for = filtered delegation. >>>=20 >>> - Do you envision this AS to be able to control access to any kind = of RS? How is the AS supposed to know what authorization data this RS = needs in order to perform access control decisions? What data will be = exchanged? >>> Yes. The whole point, as far as I'm concerned, is to design human = centered standards. This is how W3C and IETF are different. Other SDOs = tend to be operated for institutional benefit. A person-centered AS must = work across institutional domains.=20 >>>=20 >>> This, as you point out, brings up the problem of scope. Ontologies = and data models are, justifiably, domain-specific. I, for example, work = around the HL7 data model standards and APIs like FHIR that are = controlled by healthcare business interests. It's unreasonable to expect = a general solution to the data model problem, although folks of the = Linked Data persuasion might disagree. >>>=20 >>> Every RS gets to decide what data models and ontologies it supports. = These decisions are public and sometimes standardized for the benefit of = the clients. A person's AS must read and maybe understand the RS data = model in order to issue tokens just like the client needs to do in order = to make a request to the AS. In our HIE of One Trustee project, we allow = the self-sovereign subject to inherit AS policies from self-sovereign = communities they choose and then modify the policies if they want. In = this way, communities compete for members on the basis of policy bundles = the same way churches compete for congregants. >>>=20 >>> - How would this person delegate access to her resources to someone = else? >>> There are two "persons" to consider. The RO delegates to an RQ. But = the RQ, in real life, is part of a team and often delegates to = associates. With or without capabilities, GNAP needs to deal with this = reality that RO and RQ user agents may be different from the client that = actually presents a token to the RS. Some of this difference between = user agents and clients we may be able to keep out of band. >>>=20 >>> - Are you aware of deployments implementing this philosophy? >>> Other than our HIE of One demonstration project in healthcare, no. = We started HIE of One before SSI in order to drive the transition from = UMA to UMA 2.0 and inform various healthcare regulatory priorities. We = then jumped on SSI immediately and added it to the UMA 2 AS we call = Trustee. Now we are trying to align SSI and GNAP in order to enable = human-centered protocols and zero-trust architecture.=20 >>> =20 >>> - What are the implications in terms of user experience? >>> Right now, the human-centered user experience assumes a secure = element and web browser as user agents on a mobile device. Neither of = these is readily accessible as a server nor are they designed to accept = code plug-ins that represent the policies of an AS. One major exception = is people adding advertising and surveillance blockers like EFF Privacy = Badger to their browser.=20 >>>=20 >>> The user experience implications of having SSI data model standards = and GNAP protocol standards is that today's password managers (I have = 250 RS relationships in mine) will evolve to also control an AS agent. = Just like I might register a W3C DID with an RS instead of an email = address, my policy manager might display to me the token policies that = will be applied by my AS to the personal data I can control at that RS.=20= >>>=20 >>> In some cases, my AS will allow me to modify those policies just = like the obnoxious cookie policy settings do today. The BIG difference = with GNAP is that I choose my AS separately from the RS so the dark = patterns associated with today's cookie policies experience are no = longer possible. GNAP means the RS exposes an API rather than a UI. >>>=20 >>> I've gone on far too long to address the issue of the AS as an = identity provider. It's fair to think of it that way. As it turns out, = in the SSI Secure Data Storage WG, we are debating the difference = between an Encrypted Data Vault and an Identity Hub. As far as I'm = concerned, the Identity Hub is mostly a GNAP AS. Join us on Thursdays at = 4 PM ET https://lists.identity.foundation/g/sds-wg/wiki/Home = =20 >>>=20 >>> Adrian >>>=20 >>>=20 >>>=20 >>> On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt = > wrote: >>>=20 >>>=20 >>>> Am 19.02.2021 um 23:50 schrieb Adrian Gropper = >: >>>>=20 >>>> =EF=BB=BF >>>> I agree with the first two of Justin's responses but not the last = one. >>>>=20 >>>> It's confusing to think that there are more RS than AS. >>>=20 >>> the OAuth deployments I=E2=80=98m aware of typically have much more = RSs than ASs. Why? Because AS and a set of RSs belong to the same = security domain (e.g. a certain business) and it=E2=80=99s the AS=E2=80=99= s responsibility to ensure secure and convenient access to the APIs = provided by this RSs. For example: there is a AS controlling access to a = cloud, streaming, and messaging services of the same business. In case = of open banking, the bank=E2=80=98s AS is (on behalf of the user) = authorizing access to APIs for account information as well as payment = initiation and potentially other services.=20 >>>=20 >>> Technically, the respective AS and RSs set up a trust relationship = and agreed on ways to share authorization and user data in order enable = secure API access. >>>=20 >>> I read your ideas regarding self-sovereign ASs with great interest = and got some observations/questions: >>> - A personal AS could certainly control access to a person=E2=80=98s = resources. I assume the person=E2=80=98s RSs would only accept access = tokens signed by the RO. Am I right? >>> - Do you envision this AS to be able to control access to any kind = of RS? How is the AS supposed to know what authorization data this RS = needs in order to perform access control decisions? What data will be = exchanged? >>> - How would this person delegate access to her resources to someone = else? >>> - Are you aware of deployments implementing this philosophy? >>> - What are the implications in terms of user experience? >>>=20 >>> In my experience coupling between AS and RS is very tight. I have a = hard time to see how self-sovereign ASs would work. It feels like such = an AS in the end is an identity provider of some sort, which brings me = to what Justin proposed. I would assume using SSI credentials to = authenticate towards ASs is feasible and might have value but I=E2=80=98m = skeptical about the AS part. >>>=20 >>> best regards, >>> Torsten. >>>=20 >>>> =46rom a human-centered (and hopefully IETF) perspective, each = person might control or specify a different AS for each of their = personas or for each child or incompetent delegate of them as guardian. = We're familiar with separate gmail addresses for each persona. >>>>=20 >>>> ASs will be self-sovereign (as in SSI), fiduciary (as in a = custodial bitcoin wallet), or brokers (as in data brokers and = surveillance capitalism). Any RS that is willing to have a recurring = relationship with a persona could accept a GNAP AS endpoint instead of = an email address. This is easiest using HTTP, but GNAP need not exclude = other RS / AS APIs and transports. Designing around the uncensored = specification of one's AS as a human right would greatly simplify many = aspects of GNAP adoption. >>>>=20 >>>> That said, GNAP should not ignore the RS business or jurisdictional = reasons to limit the authority of the AS. UMA 2.0 spent years dancing = around this issue with ideas like "cascading" AS and various centralized = or federated AS concepts. My conclusion is that any RS can always do = whatever it wants and there's not much the authorization protocol can = help with other than specifying a notification endpoint so that an RS = can warn (and seek confirmation) or log various exceptions. This turns = out to be, after a year of testimony, the regulation that applies to = HIPAA RS APIs in the US. For this reason GNAP might include a = notification protocol in the AS specification, or not. >>>>=20 >>>> I propose that embracing a self-sovereign agent is key to = harmonizing the SSI and GNAP standards. >>>>=20 >>>> Adrian >>>>=20 >>>> On Fri, Feb 19, 2021 at 2:30 PM Justin Richer > wrote: >>>> Tobias, thanks for the great observations. Some reactions inline = below. >>>>=20 >>>>> On Feb 18, 2021, at 7:59 PM, Tobias Looker = > wrote: >>>>>=20 >>>>> Justin, >>>>>=20 >>>>> I think this is a great and timely conversation to be having given = the current interest around SSI and efforts like SIOP, I have been doing = quite a bit of work in this space as of recent, so thought I'd add a few = of the observations that I've made. >>>>>=20 >>>>> In my opinion SIOP was really a bucket for solving quite a few = different problems, not just one. In particular I think its intent was = to solve 3 major ones: >>>>>=20 >>>>> 1. Enabling portable identities >>>>> 2. Solving the NASCAR problem >>>>> 3. Exploring different deployment models for the provider >>>>>=20 >>>>> To drill down briefly on these, note much of my terminology is = OpenID based due to SIOPs origin=20 >>>>>=20 >>>>> Enabling portable identities - In general today in the case of = OpenID, the end-users identity as understood by a relying party is = scoped within the domain of the provider. Which means if that provider = goes out of business or for whatever reason decides to no longer offer = the same identity services to the End-User, their identity is = essentially gone. Whilst there has been some interesting related work = from groups like MODRNA on solutions to combat this like 'Account = Porting', they often assume the old provider remains online and willing = to facilitate in the account porting process so that the End-User can = migrate to a new provider. SIOP actually elected to do something = different here by using cryptography, instead of the End-User identifier = being something like a GUID asserted within the domain of the provider, = SIOP defined this instead as a public key fingerprint associated to a = private key that's assumed to be under the control of the user. In doing = so the identity itself becomes portable between providers by = transferring the associated private key. Now this approach does have = drawbacks and arguably encourages what many would refer to as bad = cryptographic practise by not allowing any way to do key rotation, = however the idea was there.=20 >>>>>=20 >>>>> How GNAP can solve for this? By having flexibility around how the = resource owner / End-User is referred to by the Authorization server = (e.g allow the identifier to be something like a public key or a = resolvable identifier to public keys such as a DID) >>>>=20 >>>> I personally think that GNAP should be a flexible :carrier: of = identifiers and other bits of identity information. This is the main = reason we went with the Subject Identifiers draft from SECEVENT: it=E2=80=99= s set up to talk about a variety of different kinds of identifiers, all = of them asserted in the context of the AS. If there=E2=80=99s a = definition for a DID URL or a JWK in the sub_ids object structure, GNAP = would be able to just use it directly alongside every other format. I = haven=E2=80=99t seen those proposed yet, but it would be easy to do and, = in my mind, would be a better solution than the portable identifiers = proposal that was recently brought up in the FAPI working group in OIDF. = (A side note, but the main problem I have here is that it=E2=80=99s = pasting semantics and formats onto a field where none existed before, = and that=E2=80=99s rife for problems. Better to have a structure that = takes that into account from the start, in my view.) >>>>=20 >>>>>=20 >>>>> Solving the NASCAR problem - One of those enduring problems in = identity systems, which I think is really about the three way = negotiation going on between the RP, the End-User and the Provider. = SIOP's solution pushed for most of the power in this decision making = process to lie with the End-User, letting them decide who they want as = their provider rather than RP's providing an enumeration of who they = support via provider icons on their login page and End-Users having to = select from those options. It accomplished this via using a custom URL = scheme of `openid://` <> where the End-User would register their chosen = provider as a protocol handler for the `openid://` <> scheme. However, = again as a solution it's not without it's challenges, notably; only a = single registration at a time can be supported, the actual identity of = the provider remains blind to the RP until after the request is sent and = it requires registration or some form of default handling (e.g when = there is no provider registered). >>>>>=20 >>>>> How GNAP can solve for this? I actually don't think this is core = to GNAP, there may be some considerations around discovery that are = worth paying attention to but not much in the core protocol design. >>>>>=20 >>>>=20 >>>> SIOP doesn=E2=80=99t really solve the NASCAR issue since SIOP, by = design, becomes yet one more login option among many. I think GNAP can = help this by enabling user-directed provider discovery to kick off the = process, but I agree that the core protocol doesn=E2=80=99t really have = much to say here, and shouldn=E2=80=99t. >>>>=20 >>>>> Exploring different deployment models for the provider - This is = the most frequently talked about aspect of SIOP and perhaps the most = interesting to GNAP. I like to think about the scope of this issue as = designing to allow for either a partially or fully = distributed/decentralized provider, rather than a centralized one (e.g = an HTTP based AuthZ server). As you noted this does come with its = challenges many of which are technical in nature, i.e how to = appropriately address a decentralized provider and what protocols are = used to communicate with the provider.=20 >>>>>=20 >>>>> How GNAP can solve for this? I think that's what much of the = discussion on this thread will be about and whether there is a hybrid = model where some responsibility is still centrally administered like = token issuance, while allowing other aspects to occur in a more = distributed manner. Ideally though I'd like to see consideration for a = completely distributed model too. >>>>=20 >>>> I agree that this seems to be the most interesting place for = overlap. I don=E2=80=99t actually think the =E2=80=9Chybrid=E2=80=9D = approach centralizes things. Instead, you can think of the RS as having = an associated AS, and that AS accepting user consent and claims at = runtime from a variety of sources (wallets, VCs, etc.). In this way, we = aren=E2=80=99t talking about a single AS in the world handling all of = these requests, we=E2=80=99re talking about a distributed network of = AS=E2=80=99s associated with an even more widely distributed set of = RS=E2=80=99s. SSI and its associated technologies would help these = =E2=80=9Clocal=E2=80=9D AS=E2=80=99s issue access tokens without the RO = needing to have an account, or even necessarily directly interacting = with the AS. There=E2=80=99s currently a technology gap there, but my = thoughts are that this is where the changes to the interaction modes = section can really come to play.=20 >>>>=20 >>>> I think the notion of a non-HTTP AS is interesting, but I=E2=80=99m = not sure if that=E2=80=99s something GNAP ought to be solving for. I = think that there=E2=80=99s a deep value in building on top of HTTP for = the core protocol, and not abstracting away concepts from it. Otherwise, = you end up re-inventing layers, and you get something like SOAP all over = again. :) >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> = =09 >>>>> Tobias Looker >>>>> Mattr >>>>> +64 (0) 27 378 0461 >>>>> tobias.looker@mattr.global >>>>> = = = = >>>>> This communication, including any attachments, is confidential. If = you are not the intended recipient, you should not read it - please = contact me immediately, destroy it, and do not copy or use any part of = this communication or disclose anything about it. Thank you. Please note = that this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. >>>>>=20 >>>>>=20 >>>>> On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault = > wrote: >>>>> Hi Justin, >>>>>=20 >>>>> I agree that defining AS role primarily as a token issuer is a = fruitful idea. Solving this problem well would also respond to the = challenges discussed previously on the list.=20 >>>>>=20 >>>>> Cheers >>>>> Fabien=20 >>>>>=20 >>>>>=20 >>>>> Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer = > a =C3=A9crit : >>>>> The last interim call had a lot of discussion on SSI technologies = such as digital wallets, and how those fit with GNAP. I think it=E2=80=99s= worth continuing that conversation here on the list. There are a few = issues in the tracker that give some background, too: >>>>>=20 >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 = >>>>>=20 >>>>> There=E2=80=99s been a lot of interesting work recently in the = OpenID Foundation around using the Self-issued OP (SIOP) functionality = to bootstrap an SSI style login. This makes extensive use of the = implicit flow and front channel messaging, but minimization of the front = channel for message passing is a key design tenet of GNAP (so much so = that it=E2=80=99s included in our charter). Instead, GNAP has been built = around an idea that everything starts the same way: with an HTTP request = to the AS.=20 >>>>>=20 >>>>> The idea of an on-device AS has been brought up a lot, and we need = to consider if and how we want to deal with these kinds of use cases. = The most obvious way to address these would be to do some kind of clever = off-HTTP hack like SIOP, but keep in mind that even SIOP generally = starts off with an HTTP-based discovery call by the RP to make things = work. >>>>>=20 >>>>> My personal stance is that to do this, we need to re-evaluate our = assumptions about exactly what an AS does and what it needs to do those = things. In OAuth 2, it=E2=80=99s assumed that the AS is the device = that=E2=80=99s authenticating the user, collecting consent, managing the = client=E2=80=99s registration, and creating an access token based on = whatever set of rights that are associated with all of those things. In = UMA, this is turned around a bit by letting the RO present a bunch of = nebulous =E2=80=9Cclaims=E2=80=9D interactively, but still at the AS.=20 >>>>>=20 >>>>> With both of these, a key aspect remains: the AS needs to gather = necessary information, and issue the access token (or = identifiers/assertions). Because of how the protocol works, the client = software now has a better opportunity to present information to the AS, = either directly in the request or by introducing the AS to another = software component during the =E2=80=9Cinteraction=E2=80=9D phase. So, = what if we think of the AS primarily as a =E2=80=9Ctoken issuer=E2=80=9D?=20= >>>>>=20 >>>>> For example, if the client can present a verifiable credential = (VC) that represents the end user, the AS can validate that VC and make = an access token on behalf of that user, without having the user log in = or interact with the AS at all. This VC can contain whatever access = rights the token needs to represent, and the AS can translate that into = an artifact that the downstream RS=E2=80=99s can interpret, without = having to see the original VC or the user at all. The AS is still HTTP = based, but all the essential security and rights elements are provided = by the wallet. In this way, we can expand on the privacy-preserving = aspects of OAuth and bridge the worlds of SSI and web APIs without = violating the basic nature of either. >>>>>=20 >>>>> Coming from the OAuth world, it feels weird to issue tokens like = this, but there=E2=80=99s precedent for this kind of thing. Today, a = there are a number of service-based OAuth AS's that are told what claims = need to get put into the access token by some trusted component. All of = this happens outside the OAuth protocol. In GNAP, I think it makes sense = to account for this kind of thing in how we define the protocol. That = isn=E2=80=99t to say all of these pieces need to be defined in the core, = but the base protocol ought to be able to handle being extended in this = direction as needed. >>>>>=20 >>>>> I=E2=80=99m really interested to hear other people=E2=80=99s = thoughts on how this could come together. >>>>>=20 >>>>> =E2=80=94 Justin >>>>> --=20 >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>> --=20 >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>>=20 >>>>> This communication, including any attachments, is confidential. If = you are not the intended recipient, you should not read it - please = contact me immediately, destroy it, and do not copy or use any part of = this communication or disclose anything about it. Thank you. Please note = that this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. >>>>=20 >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txaut= h&source=3Dgmail-imap&ust=3D1614379828000000&usg=3DAOvVaw3avsUGQ48fo1OUQV0= vyyKd = >>=20 >>=20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_0D9660AF-142C-4D26-9F72-7DF5F7AFFBA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 = to this. In my opinion, building on anything other than HTTP right now = is speculation, at best. And building an abstraction from zero-to-one = concrete manifestations is a recipe for disaster. Once a second thing = comes along, you inevitably realize that you put the abstraction points = in the wrong place and have in fact baked in a lot of assumptions about = your base case into what was supposed to be an abstraction = layer. 

    Instead, = if there=E2=80=99s a desire to build out GNAP on top of other protocols, = then it should be :translated: to those protocols. This happened with = OAuth being built on top of COAP in ACE, without OAuth defining an = abstraction layer ahead of time. And I=E2=80=99ll wager that if we had = defined such a layer, it would not have considered things like the = multi-tiered client structures that are in ACE, or the key distribution = challenges in the IoT environment. Abstractions can come after the fact = to aid future translations, but translation is nearly always more = practical. 

    But my point in starting this thread is that I think we can = set up appropriate extension points for novel elements without throwing = out the entire base protocol, or creating something overly abstract. So = I think we can keep the =E2=80=9CAS=E2=80=9D component and the central = HTTP-based protocol but have places where these other elements, like SSI = wallets, can come in. I think we need to get away from the false = conclusion that the SSI wallet has to :be: the AS. Instead, I think the = SSI wallet can feed information into an AS in order for the AS to do its = job.

     =E2=80= =94 Justin

    On Feb 24, 2021, at 12:47 PM, = Adrian Gropper <agropper@healthurl.com> wrote:

    It might help the GNAP scoping = discussion relative to SSI if we consider two separate = domains: 
    - Registration: The = relationship between the RO and the RS prior to any GNAP Client entering = the picture, and
    - Authorization: = The interaction protocols between the user agents of end users and = servers

    Fact: = Only two SSI standards (VC and DID) are established enough for us to = reference in GNAP and they are both merely data models, not protocols. = Neither of these data models is particularly concerned with = delegation protocols although there is going to be some impact from = things like multi-signature schemes and filtering of = capabilities.

    IMHO, GNAP as a delegation protocol standard cannot = presume the success or applicability of any SSI inspired protocols, = including DIDcomm or Confidential Storage, that are still trying to = figure out their relationship to HTTP. 

    Also, IMHO, SSI is not synonymous with = protocols that presume a Holder as a mandated intermediary store for any = attribute that moves between an issuer and a verifier. There are many, = maybe most, use cases where SSI would be better served by control of the = attribute over actual possession of the attribute.

    Adrian



    On Wed, Feb 24, 2021 at 12:09 PM = Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:
    Integrating GNAP and SSI requires a lot of fundamentals:

    • AS had their essence in the fact that = human held devices were not able to produce authorization sharable to = client and RS
    • If the human = held device can do the work, it is natural the momentum will shift in = that direction. This is what is happening with SSI.
    • Sharing all views of Adrian mention in this = thread(no need to repeat). 
    • But repeating the keyword: ZTA. Keeping custodian, server = centered architectures under control is getting tougher as time goes = by.
    In GNAP initial discussion, we walked through a lot of abstract diagram, = that could have allowed production of authorization and authentication = material (token) by human held devices. The intention was inspired from = SSI discussions. 

    IF
      Justin is asking to reconsider an integration of SSI,

    THEN
    we need to review the abstract protocol = flows:
    • roles
    • entities
    • relationships
    We will have to start by taking the http protocol constraint out of the = charter.

    BTW
    • I agree with Justin: "The RS decides on how to consume a = presented token."
    • I agree with Denis: "AS plays no = role and shall have no influence on the RS decision on how to consume a = token."

    THEN
    We must start by sharping the meaning of an AS (in the context of GNAP). = Discussion might lead to a retirement of this term. As mortals might = have a hard time considering a user held device a server.

    END IF


    Nevertheless, the transition from (http)-AS based token production to = user device-based token production will need some 10+ years to complete. = Still a lot of challenges around how to protect keys held on user = devices against damage, loss of device, malware, ransomware, social engineered attack.

    Can GNAP be the main vehicle for this transition? Maybe. Despite the = (too) strong reliance on the OAuth legacy (even if GNAP does not promise = backward compatibility to OAuth), an embedded interaction that allows the client to carry = the user device produced token to the resource server might pave way for = this transition. I campaigned for consideration of an embedded interaction in the initial conversation. I am = not sure this was taken into account. Still must find time to review the = current draft.


    /Francis


    From: TXAuth <txauth-bounces@ietf.org> on behalf of Denis <denis.ietf@free.fr>
    Sent: Tuesday, February 23, 2021 12:51 PM
    = To: Justin Richer <jricher@mit.edu>; txauth gnap = <txauth@ietf.org>
    Subject: Re: [GNAP] Integrating a GNAP AS with wallets = and SSI
     
    Hi  Justin,

    See my comments between the lines.
    An important aspect in the = discussion here, that I agree with, is that the RS needs to be able to = decide which AS it talks to. =

     While = I would agree with such a sentence in the OAuth WG, I don't believe that = this sentence is applicable in general in the context of GNAP.
    A RS does not need to "talk to" any AS. A RS decides which AS(s) it = trusts to issue access tokens that contains some set of privileges.

    But inherent in that is that it=E2=80= =99s not the user=E2=80=99s decision, or the AS=E2=80=99s decision, = it=E2=80=99s the RS=E2=80=99s decision who it will trust to get tokens = from.

    A RS does = not necessarily need to trust all the access tokens issued by a given = AS, but only access tokens from a given AS that contain
    a given set of privileges.

    And no matter what our philosophy, = at the end of the day the RS will always have the choice of whether to = trust an inbound request.

    Not exactly: the RS will apply the rules = given by the RO.

    Which is why, to me, this really brings us to the = question of what an AS provides. The AS gives the RS a token that the RS = decides to trust,
    and that the RS can understand (either directly with something like JWT = or indirectly with something like introspection).
    But the AS also needs to decide what to put INTO that token. As a = consequence, the AS can get that information from any number of = places.
    The information could be provided in a trusted way by the end user to = the AS =E2=80=94 but this does NOT necessarily mean that the AS belongs
    to the user or is under their control. 

    Basically, I think we=E2=80=99re trying to hard to map = the OAuth general-concept of the RO having an account at the AS and = logging in to it before authorizing the request.
    I think that the call for =E2=80=9Cevery user to have their own AS=E2=80=9D= is such a huge non-starter in so many domains that it hampers the = solution space if that=E2=80=99s what we presume.
    It=E2=80=99s up to the RS to decide who it trusts, not the end user and = not the RO. 

    I think we should ALLOW it, and we can be clearer in = GNAP that that=E2=80=99s one possible model, but not the only one, and = not even the general one.
    The AS manages all of the information and interconnections needed to = create an access token that the RS will accept, and it is in charge of = signaling to the RS what that token=E2=80=99s good for.

    I = disagree: the AS is NOT in charge of signaling to the RS what that = token=E2=80=99s good for. It is up to the RS to decide which privileges = it will accept
    among all the privileges included into an access token.

    However, if the AS can learn through some other means = that a specific identified user has consented and provided appropriate = information in a trusted way,
    then THAT information can be baked into the token by the AS. =E2=80=94 = importantly, in a way that the RS=E2=80=99s = the AS protects can understand.

    I = disagree: Trust relationships are not bilateral but only unilateral. An = AS does not need to have any specific prior relationship with a given = RS.
    It is up to the RS(s) to decide which AS(s) it trust(s) and for which = privileges.

    This last bit is where general opacity of tokens is important here. There=E2=80=99s = a natural security boundary that arises from this model. What I=E2=80=99m = proposing here is just that we=E2=80=99re more explicit about what can = be put INTO that boundary. That=E2=80=99s where I=E2=80=99m seeing a lot of this innovation in the = SSI space fitting. You=E2=80=99re not coming up with some universal = access token that the RS will accept, but you=E2=80=99re able to provide = universal claims and artifacts that an AS can process and translate into a token the RS will accept = and do the right thing with.

    Your = argumentation about token opacity is making the assumption that the AS = and the RS need to have a prior relationship before any access can take = place.
    While this was valid with OAuth, this is no more valid in the context of = GNAP.  The client should be able to inform the AS about the access = token format(s) acceptable to the RS.
    Then the client may indicate to the AS these acceptable formats. If the = RS and the AS have an access token format in common, then the process = may continue.

    When only = attributes (i.e. not rights) are being requested to an AS by the client, = the client does not need to disclose the identity of the RS to the AS,
    which has the major advantage to prevent the AS to act as Big = Brother.

        Note: this does not = preclude the use of rights, in particular in the context of a single = organization or enterprise.

    Denis


     =E2=80=94 Justin

    On Feb 21, 2021, at 9:40 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    Hi Torsten,

    Thank you for raising all of these excellent points. I = hope we can all answer them and maybe even add a section to the wiki. = I'll start...

    You're right that OAuth deployments almost exclusively = put the AS and RS in the same domain. If OAuth were adequate to today's = needs we probably would not be here doing GNAP. Since OAuth, we have = increasing privacy concerns and security disasters. GDPR, for example, separates the role of a data controller from a data = processor and treats them as separate legal entities. To oversimplify = GDPR, the data processor is spared privacy responsibility and = cost.

    You are also right to mention open banking as a = use-case. Open banking has not adopted UMA 2.0 (on which I have worked = for almost a decade) which is based on OAuth. PSD2 and similar = regulations do not tie the AS and RS to the same security domain but they presume a narrow federation of licensed (and regulated) ASs as = payment processors for subjects to choose among. This centralization to = regulated fiduciaries is a privacy trade-off that makes sense in = banking. The fiduciary can be bonded so they can refund the money to the subject in case of a security breach. This = privacy-security tradeoff does not make sense in healthcare and other = domains where the consequences of a breach are not easily = reversed.

    This thread is about aligning GNAP and SSI. SSI does not = abide centralization, censorship, or surveillance. If GNAP makes any = assumptions that result in either a tight coupling between AS and RS = (surveillance) or even a federated fiduciary (centralization) we will lose out on the benefits of progress in digital identity that = is now driving a lot of public-sector initiatives and starting to bleed = over into private sector practices. Zero Trust Architecture is an = example and OAuth is not well suited for ZTA.

    As you said, "technically, the respective AS and RSs set = up a trust relationship and agreed on ways to share authorization and = user data in order [to] enable secure API access." This is where GNAP = operates and we need to avoid _any_ restrictions on either the AS or the RS being self-sovereign. Examples of a = self-sovereign RS could be a personal data store or an encrypted data = vault like the ones we work on in W3C/DIF. Any AS can be self-sovereign = if the subject controls all of the policies and these policies are not shared, in the same way a private key is never not = shared. 

    Continuing your quote:
    I read your ideas regarding self-sovereign ASs with great interest and = got some observations/questions:
    - A personal AS could certainly control access to a person=E2=80=98s = resources. I assume the person=E2=80=98s RSs would only accept access = tokens signed by the RO. Am I right?
    Yes, and. There is debate in various SSI WGs whether a = RS such as an Encrypted Data Vault should respond to capabilities or = tokens. Either way, the RO is in control of the signature but a personal = AS is a delegate of the RO (either directly or via a mobile user agent). With capabilities such as ZCAP-LD or = biscuits, the token signature allows for filtered delegation.

    - Do you envision this AS to be able to control access to any kind of = RS? How is the AS supposed to know what authorization data this RS needs = in order to perform access control decisions? What data will be = exchanged?
    Yes. The whole point, as far as I'm concerned, is to = design human centered standards. This is how W3C and IETF are different. = Other SDOs tend to be operated for institutional benefit. A = person-centered AS must work across institutional domains. 

    This, as you point out, brings up the problem of scope. = Ontologies and data models are, justifiably, domain-specific. I, for = example, work around the HL7 data model standards and APIs like FHIR = that are controlled by healthcare business interests. It's unreasonable to expect a general solution to the data model = problem, although folks of the Linked Data persuasion might = disagree.

    Every RS gets to decide what data models and ontologies = it supports. These decisions are public and sometimes standardized for = the benefit of the clients. A person's AS must read and maybe understand = the RS data model in order to issue tokens just like the client needs to do in order to make a request to the AS. = In our HIE of One Trustee project, we allow the self-sovereign subject = to inherit AS policies from self-sovereign communities they choose and = then modify the policies if they want. In this way, communities compete for members on the basis of policy bundles the = same way churches compete for congregants.

    - How would this person delegate access to her resources to someone = else?
    There are two "persons" to consider. The RO delegates to = an RQ. But the RQ, in real life, is part of a team and often delegates = to associates. With or without capabilities, GNAP needs to deal with = this reality that RO and RQ user agents may be different from the client that actually presents a token to = the RS. Some of this difference between user agents and clients we = may be able to keep out of band.

    - Are you aware of deployments implementing this philosophy?
    Other than our HIE of One demonstration project in = healthcare, no. We started HIE of One before SSI in order to drive the = transition from UMA to UMA 2.0 and inform various healthcare = regulatory priorities. We then jumped on SSI immediately and added it to the UMA 2 AS we call Trustee. Now we are trying to align = SSI and GNAP in order to enable human-centered protocols and zero-trust = architecture. 
     
    - What are the implications in terms of user experience?
    Right now, the human-centered user experience assumes a = secure element and web browser as user agents on a mobile device. = Neither of these is readily accessible as a server nor are they = designed to accept code plug-ins that represent the policies of an AS. One major exception is people adding advertising and = surveillance blockers like EFF Privacy Badger to their = browser. 

    The user experience implications of having SSI data = model standards and GNAP protocol standards is that today's password = managers (I have 250 RS relationships in mine) will evolve to also = control an AS agent. Just like I might register a W3C DID with an RS instead of an email address, my policy manager might display = to me the token policies that will be applied by my AS to the personal = data I can control at that RS. 

    In some cases, my AS will allow me to modify those = policies just like the obnoxious cookie policy settings do today. The = BIG difference with GNAP is that I choose my AS separately from the RS = so the dark patterns associated with today's cookie policies experience are no longer possible. GNAP means the RS exposes = an API rather than a UI.

    I've gone on far too long to address the issue of the AS = as an identity provider. It's fair to think of it that way. As it turns = out, in the SSI Secure Data Storage WG, we are debating the difference = between an Encrypted Data Vault and an Identity Hub. As far as I'm concerned, the Identity Hub is mostly a GNAP AS. = Join us on Thursdays at 4 PM ET https://lists.identity.foundation/g/sds-wg/wiki/Home <= /div>

    Adrian



    On Sun, Feb 21, 2021 at 4:34 AM Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:


    Am 19.02.2021 um 23:50 schrieb = Adrian Gropper <agropper@healthurl.com>:

    =EF=BB=BF
    I agree with the first two of = Justin's responses but not the last one.

    It's confusing to think that there are more RS than = AS.

    the OAuth deployments I=E2=80=98m aware of typically = have much more RSs than ASs. Why? Because AS and a set of RSs belong to = the same security domain (e.g. a certain business) and it=E2=80=99s the = AS=E2=80=99s responsibility to ensure secure and convenient access to the APIs provided by this RSs. For example: there is a AS controlling = access to a cloud, streaming, and messaging services of the same = business. In case of open banking, the bank=E2=80=98s AS is (on behalf = of the user) authorizing access to APIs for account information as well as payment initiation and potentially other = services. 

    Technically, the respective AS and RSs set up a trust = relationship and agreed on ways to share authorization and user data in = order enable secure API access.

    I read your ideas regarding self-sovereign ASs with = great interest and got some observations/questions:
    - A personal AS could certainly control access to a = person=E2=80=98s resources. I assume the person=E2=80=98s RSs would only = accept access tokens signed by the RO. Am I right?
    - Do you envision this AS to be able to control access = to any kind of RS? How is the AS supposed to know what authorization = data this RS needs in order to perform access control decisions? What = data will be exchanged?
    - How would this person delegate access to her resources = to someone else?
    - Are you aware of deployments implementing this = philosophy?
    - What are the implications in terms of user = experience?

    In my experience coupling between AS and RS is very = tight. I have a hard time to see how self-sovereign ASs would work. It = feels like such an AS in the end is an identity provider of some sort, = which brings me to what Justin proposed. I would assume using SSI credentials to authenticate towards ASs is feasible = and might have value but I=E2=80=98m skeptical about the AS part.

    best regards,
    Torsten.

    =46rom a human-centered (and hopefully IETF) = perspective, each person might control or specify a different AS for = each of their personas or for each child or incompetent delegate of them = as guardian. We're familiar with separate gmail addresses for each persona.

    ASs will be self-sovereign (as in SSI), fiduciary (as in = a custodial bitcoin wallet), or brokers (as in data brokers and = surveillance capitalism). Any RS that is willing to have a recurring = relationship with a persona could accept a GNAP AS endpoint instead of an email address. This is easiest using HTTP, but GNAP need = not exclude other RS / AS APIs and transports. Designing around the = uncensored specification of one's AS as a human right would greatly = simplify many aspects of GNAP adoption.

    That said, GNAP should not ignore the RS business or = jurisdictional reasons to limit the authority of the AS. UMA 2.0 = spent years dancing around this issue with ideas like "cascading" AS and = various centralized or federated AS concepts. My conclusion is that any RS can always do whatever it wants and there's not much the = authorization protocol can help with other than specifying a = notification endpoint so that an RS can warn (and seek confirmation) or = log various exceptions. This turns out to be, after a year of testimony, the regulation that applies to HIPAA RS APIs in = the US. For this reason GNAP might include a notification protocol in = the AS specification, or not.

    I propose that embracing a self-sovereign agent is key = to harmonizing the SSI and GNAP standards.

    Adrian

    On Fri, Feb 19, 2021 at 2:30 PM Justin = Richer <jricher@mit.edu> wrote:
    Tobias, thanks for the great observations. Some reactions = inline below.

    On Feb 18, 2021, at 7:59 PM, Tobias Looker <tobias.looker@mattr.global> wrote:

    Justin,

    I think this is a great and timely conversation to be having given the = current interest around SSI and efforts like SIOP, I have been doing = quite a bit of work in this space as of recent, so thought I'd add a few = of the observations that I've made.

    In my opinion SIOP was really a bucket for solving quite a few different = problems, not just one. In particular I think its intent was to solve 3 = major ones:

    1. Enabling portable identities
    2. Solving the NASCAR problem
    3. Exploring different deployment models for the provider

    To drill down briefly on these, note much of my terminology is OpenID = based due to SIOPs origin 

    Enabling portable identities - In general today in the = case of OpenID, the end-users identity as understood by a relying party = is scoped within the domain of the provider. Which means if that = provider goes out of business or for whatever reason decides to no longer offer the same identity services to the End-User, = their identity is essentially gone. Whilst there has been some = interesting related work from groups like MODRNA on solutions to combat = this like 'Account Porting', they often assume the old provider remains online and willing to facilitate in the account = porting process so that the End-User can migrate to a new provider. SIOP = actually elected to do something different here by using cryptography, = instead of the End-User identifier being something like a GUID asserted within the domain of the provider, SIOP defined = this instead as a public key fingerprint associated to a private key = that's assumed to be under the control of the user. In doing so the = identity itself becomes portable between providers by transferring the associated private key. Now this approach does have = drawbacks and arguably encourages what many would refer to as bad = cryptographic practise by not allowing any way to do key rotation, = however the idea was there. 

    How GNAP can solve for this? By having = flexibility around how the resource owner / End-User is referred to by = the Authorization server (e.g allow the identifier to be something like = a public key or a resolvable identifier to public keys such as a DID)

    I personally think that GNAP should be a flexible = :carrier: of identifiers and other bits of identity information. This is = the main reason we went with the Subject Identifiers draft from = SECEVENT: it=E2=80=99s set up to talk about a variety of different kinds of identifiers, all of them asserted in the context of the AS. If = there=E2=80=99s a definition for a DID URL or a JWK in the sub_ids = object structure, GNAP would be able to just use it directly alongside = every other format. I haven=E2=80=99t seen those proposed yet, but it would be easy to do and, in my mind, would be a better solution = than the portable identifiers proposal that was recently brought up in = the FAPI working group in OIDF. (A side note, but the main problem I = have here is that it=E2=80=99s pasting semantics and formats onto a field where none existed before, and that=E2=80=99s rife = for problems. Better to have a structure that takes that into account = from the start, in my view.)


    Solving the NASCAR problem - One of those enduring = problems in identity systems, which I think is really about the three = way negotiation going on between the RP, the End-User and the Provider. = SIOP's solution pushed for most of the power in this decision making process to lie with the End-User, letting them = decide who they want as their provider rather than RP's providing an = enumeration of who they support via provider icons on their login page = and End-Users having to select from those options. It accomplished this via using a custom URL scheme of `openid://` where the End-User would register their chosen = provider as a protocol handler for the `openid://` = scheme. However, again as a solution it's not without it's challenges, notably; only a single registration at a time can be supported, the = actual identity of the provider remains blind to the RP until after the = request is sent and it requires registration or some form of default = handling (e.g when there is no provider registered).

    How GNAP can solve for this? I actually don't think = this is core to GNAP, there may be some considerations around discovery = that are worth paying attention to but not much in the core protocol = design.


    SIOP doesn=E2=80=99t really solve the NASCAR issue since = SIOP, by design, becomes yet one more login option among many. I think = GNAP can help this by enabling user-directed provider discovery to kick = off the process, but I agree that the core protocol doesn=E2=80=99t really have much to say here, and shouldn=E2=80=99t.
    Exploring different deployment models for = the provider - This is the most frequently talked about aspect of = SIOP and perhaps the most interesting to GNAP. I like to think about the = scope of this issue as designing to allow for either a partially or fully distributed/decentralized provider, rather = than a centralized one (e.g an HTTP based AuthZ server). As you = noted this does come with its challenges many of which are technical in = nature, i.e how to appropriately address a decentralized provider and what protocols are used to communicate with the provider. =

    How GNAP can solve for this? I think that's what = much of the discussion on this thread will be about and whether there is = a hybrid model where some responsibility is still centrally administered = like token issuance, while allowing other aspects to occur in a more distributed manner. Ideally though I'd like to see = consideration for a completely distributed model too.

    I agree that this seems to be the most interesting place = for overlap. I don=E2=80=99t actually think the =E2=80=9Chybrid=E2=80=9D = approach centralizes things. Instead, you can think of the RS as having = an associated AS, and that AS accepting user consent and claims at runtime from a variety of sources (wallets, VCs, etc.). In this way, we = aren=E2=80=99t talking about a single AS in the world handling all of = these requests, we=E2=80=99re talking about a distributed network of = AS=E2=80=99s associated with an even more widely distributed set of = RS=E2=80=99s. SSI and its associated technologies would help these =E2=80=9Clocal=E2=80= =9D AS=E2=80=99s issue access tokens without the RO needing to have an = account, or even necessarily directly interacting with the AS. There=E2=80= =99s currently a technology gap there, but my thoughts are that this is where the changes to the interaction modes section can really come to = play. 

    I think the notion of a non-HTTP AS is interesting, but = I=E2=80=99m not sure if that=E2=80=99s something GNAP ought to be = solving for. I think that there=E2=80=99s a deep value in building on = top of HTTP for the core protocol, and not abstracting away concepts = from it. Otherwise, you end up re-inventing layers, and you get something like = SOAP all over again. :)

     =E2=80=94 Justin


    Thanks,
    3D"Mattr  
    Tobias = Looker
    Mattr
    +64 (0) 27 = 378 0461
    tobias.looker@mattr.global
    =
    3D"Mattr 3D"Mattr 3D"Mattr 3D"Mattr

    This communication, including any attachments, is = confidential. If you are not the intended recipient, you should not read = it - please contact me immediately, destroy it, and do not copy or use = any part of this communication or disclose anything about it. Thank you. Please note that this communication does = not designate an information system for the purposes of the Electronic = Transactions Act 2002.


    On Thu, Feb 18, 2021 at 9:19 PM Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi Justin,

    I agree that defining AS role primarily as = a token issuer is a fruitful idea. Solving this problem well would also = respond to the challenges discussed previously on the list. 

    Cheers
    Fabien 


    Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, = Justin Richer <jricher@mit.edu> a =C3=A9crit :
    The last interim call had a lot of discussion on SSI = technologies such as digital wallets, and how those fit with GNAP. I = think it=E2=80=99s worth continuing that conversation here on the list. = There are a few issues in the tracker that give some background, too:

    https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175

    There=E2=80=99s been a lot of interesting work recently = in the OpenID Foundation around using the Self-issued OP (SIOP) = functionality to bootstrap an SSI style login. This makes extensive use = of the implicit flow and front channel messaging, but minimization of the front channel for message passing is a key design tenet of GNAP = (so much so that it=E2=80=99s included in our charter). Instead, GNAP = has been built around an idea that everything starts the same way: with = an HTTP request to the AS. 

    The idea of an on-device AS has been brought up a lot, = and we need to consider if and how we want to deal with these kinds of = use cases. The most obvious way to address these would be to do some = kind of clever off-HTTP hack like SIOP, but keep in mind that even SIOP generally starts off with an HTTP-based = discovery call by the RP to make things work.

    My personal stance is that to do this, we need to = re-evaluate our assumptions about exactly what an AS does and what it = needs to do those things. In OAuth 2, it=E2=80=99s assumed that the AS = is the device that=E2=80=99s authenticating the user, collecting = consent, managing the client=E2=80=99s registration, and creating an access = token based on whatever set of rights that are associated with all of = those things. In UMA, this is turned around a bit by letting the RO = present a bunch of nebulous =E2=80=9Cclaims=E2=80=9D interactively, but = still at the AS. 

    With both of these, a key aspect remains: the AS needs = to gather necessary information, and issue the access token (or = identifiers/assertions). Because of how the protocol works, the client = software now has a better opportunity to present information to the AS, either directly in the request or by introducing the AS to = another software component during the =E2=80=9Cinteraction=E2=80=9D = phase. So, what if we think of the AS primarily as a =E2=80=9Ctoken = issuer=E2=80=9D? 

    For example, if the client can present a verifiable = credential (VC) that represents the end user, the AS can validate that = VC and make an access token on behalf of that user, without having the = user log in or interact with the AS at all. This VC can contain whatever access rights the token needs to represent, and = the AS can translate that into an artifact that the downstream RS=E2=80=99= s can interpret, without having to see the original VC or the user at = all. The AS is still HTTP based, but all the essential security and rights elements are provided by the wallet. In this way, = we can expand on the privacy-preserving aspects of OAuth and bridge the = worlds of SSI and web APIs without violating the basic nature of = either.

    Coming from the OAuth world, it feels weird to issue = tokens like this, but there=E2=80=99s precedent for this kind of thing. = Today, a there are a number of service-based OAuth AS's that are told = what claims need to get put into the access token by some trusted component. All of this happens outside the OAuth protocol. In = GNAP, I think it makes sense to account for this kind of thing in how we = define the protocol. That isn=E2=80=99t to say all of these pieces need = to be defined in the core, but the base protocol ought to be able to handle being extended in this direction as = needed.

    I=E2=80=99m really interested to hear other people=E2=80=99= s thoughts on how this could come together.

     =E2=80=94 Justin
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    =
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    = 

    This communication, including any attachments, is =
confidential. If you are not the intended recipient, you should not read =
it - please contact me immediately, destroy it, and do not copy or use =
any part of this communication or disclose anything about it. Thank you. =
Please note that this communication does not designate an information =
system for the purposes of the Electronic Transactions Act 2002.

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    =
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/lis= tinfo/txauth&source=3Dgmail-imap&ust=3D1614379828000000&usg=3D= AOvVaw3avsUGQ48fo1OUQV0vyyKd



    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    =

    = --Apple-Mail=_0D9660AF-142C-4D26-9F72-7DF5F7AFFBA6-- From nobody Wed Feb 24 17:15:11 2021 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 8CD223A0A3B for ; Wed, 24 Feb 2021 17:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=adorsys.de 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 dCMtNyvpTOi6 for ; Wed, 24 Feb 2021 17:15:01 -0800 (PST) Received: from DEU01-BE0-obe.outbound.protection.outlook.com (mail-be0deu01on2116.outbound.protection.outlook.com [40.107.127.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028A93A0A34 for ; Wed, 24 Feb 2021 17:15:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mkUj3mA2fMUR5EylefvcSUplSTxgFZu1/jgfeEVu8UztUkVH6Wlya5EKN3KwZhLQ6ltia/YHBH1hDJYt/LHQbC5Btk6Bwru46TMm/8LO7FPakD2jBNSpV+Wi9sXqbuq7QOJPNfcCGviwCT9kYHumjID0b2dQFHzVnADMN649w0PCtuJ0KVHOU0ko79M0micqy48akmF48dlNv4PucPDVDKRLUfWVeVAJA6lZWOLe3+3QbHnTumY7eJr1QN72eV2p0mXt4gD4+wI/faSXGzOiukdHvmy++e6WPyUqf+/oudYqE7oc7Zs0X+ZJ3iQ2xHwRWlN/N7RzUxy6Jdr4EkmhXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GhAF26J/1e0hUkEJhz/qlZAp/4waP+k1irGNjZ2jFl8=; b=GkaA7hCYqDxPxMzVIqpOc+ajykgtpTHRPtSTqd2OVn1qZpK76hT/h89Td+PSFHUDbCov4HMpmRN4tbXPABgxHbE47ox/5Q2NjM2m9tHsl6pizfY0ioJ1H1DV3Zwk/7WFmBgK37zOoY/+Y17lF4KD1l++5PL2GUrQhdKeFzzNIvrOr58+kdr0L8sWXlIN/xOpBv9T1RabP0UTLG9NnP5g/awg5av1YtFVAxOAH1/EE/Y8kEyVS117KEaaNULfxOP7FCtqt7BNi0+10fM45BolaAAwrSQqxw9lFegcx4rIXOhclwm67LqBAfr42g5/Avs9JFiR/CoVe3pmF3Zd1HA46g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=adorsys.de; dmarc=pass action=none header.from=adorsys.de; dkim=pass header.d=adorsys.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GhAF26J/1e0hUkEJhz/qlZAp/4waP+k1irGNjZ2jFl8=; b=urARC7Z78m9kHHcG0/uunfM1k6UcyVWu+DgOMktilP8jKFAAs3u38dh8g4pRkNTslS8M7C53cm5zMYpjKkyR9LKfEs+I3dRW7GEXu9eWBmhmGOZgRJjzYGMQTefYE8TL3cWNIBK1PTajVTzOX++DM8WSe1PBAy29565tdxx9Jpng+RzLWxmBIVfX/NPMLWwjA3omXExYV2trESMWPdRLyfOG267fIkCVmykhrpyTrB5u10zqvo0euuH80OEtieR8KJpQN6dZGJy97anzTTNBtkU2NQ43Zk5gplsrKBYNFsUQNzkrfTTeKEZuaBf2M/pMRe9y/ZA3/rNH31RSZB1LiQ== Received: from FR2P281MB0138.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:10::8) by FRYP281MB0173.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:6::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.9; Thu, 25 Feb 2021 01:14:57 +0000 Received: from FR2P281MB0138.DEUP281.PROD.OUTLOOK.COM ([fe80::bc2b:fddf:d610:ee71]) by FR2P281MB0138.DEUP281.PROD.OUTLOOK.COM ([fe80::bc2b:fddf:d610:ee71%3]) with mapi id 15.20.3912.009; Thu, 25 Feb 2021 01:14:57 +0000 From: Francis Pouatcha To: Justin Richer , Adrian Gropper CC: Francis Pouatcha , Denis , txauth gnap Thread-Topic: [GNAP] Integrating a GNAP AS with wallets and SSI Thread-Index: AQHXBXwe7b9/rWIGR0yOF6btTivnUKpdknMAgAEXjYCAATZHgIAAN+AAgAJGUgCAAFWagIAB1VCAgAEwxwCAAcSN74AAIH+AgAATxICAAFhA4YAAEPcf Date: Thu, 25 Feb 2021 01:14:57 +0000 Message-ID: References: <4EAA60A4-4800-400F-A70A-F7B7F1A6CB0A@mit.edu> <73cd4e8b-c843-ab87-c640-eea763b6002a@free.fr> , <34DD2820-06F8-4226-A987-DF6F1105B87D@mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=adorsys.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2603:9000:780a:f3b8:9035:d2d:198b:699a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4b2b37e1-b3eb-4c1d-ebfc-08d8d92ac445 x-ms-traffictypediagnostic: FRYP281MB0173: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4303; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HIjEMyMGiS77iKLytMxmEkrsVulpBaoFvXjlk7+Djt/9xiJpQtOpV0UEY3UIHo0n7J5nEvEnFM9rTAOTUw9ONYE2ijhYzvANYDnqJhGHxW5q/p88yyhqPsEQOQOG873DmLLn/c4wzngaQMH7srRsL/CeMIdyTG/FvK6Ai5T9vcaZl0o5QyyufCoFY2a9bTX8AbUeHHb9N1INTqAi/z60cvleStC7jtoz1MSAmWHE3HKmstXuV7YWFzYWsxurmhAYajzKB4xs5m/T+H2vi2lwvzM7jK5+OvovMYMoQy2QIEhFA5QkpP4IiPKkNOC+yjfylf+EQ4iTox39pPYcZtVGKWnURP/vOim6LUfUa15pDtEF3Y9voyw5dsASB/K5jVOoQRRn5CpIagwNFTauwK4CRa4+WyorT49v71DPHG3pJJZAZo3ULR4HM6bzW06qymmCbVPKhuktnWiCDujs6aCdxuX+BV/i4igr5OGN/H6xh+QhucFx8YHvY7oIvQwu9RN7edGVs/cKIcoWovgyo7O8sDS83hOE+cHG1vvL4M+Q8Xj24x84pC2Az+pIHquOD29gGQf2EtdA8QKsGGhfg+tvcORl3GfNCoFcXWu/B9JgDX3pDDpSGzdSzF0crZHiqbqzlZQMpByU+4QbQBvUbN9K1w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0138.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(39830400003)(346002)(366004)(396003)(19627405001)(110136005)(316002)(64756008)(54906003)(66476007)(55016002)(4326008)(66556008)(71200400001)(66446008)(83380400001)(9686003)(66574015)(76116006)(66946007)(91956017)(18074004)(86362001)(166002)(186003)(8676002)(7696005)(6506007)(53546011)(8936002)(2906002)(2940100002)(30864003)(966005)(5660300002)(52536014)(33656002)(478600001)(15866825006)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?iAs4aFI6ciDu3C+jNzoHtMTw5zcwAkO4Qg5MOpW32LiObvbPRfa4wSYZ?= =?Windows-1252?Q?a9ByJ9DlCEiLj67zph/XUymswzmy8b3M9zIF2f63NDRa6Sygq3X4blZu?= =?Windows-1252?Q?w9qayhKkr0YpJNS3T5PDcdQUlxQBUOkhTu82gsPTvS+zYU80TYsH3Vui?= =?Windows-1252?Q?2LYa94F+BdQmI9WVv0gndMrWwayTP1rCtZa3NWYY4UB3PGdSFoQMhkL9?= =?Windows-1252?Q?tNzyiMdoHF/yjLr2dRXgG2mqlFaZaFeaehBcN6Cin4UiwM4LHgb6whWj?= =?Windows-1252?Q?EGQD9MeEehmAGtvXLtuWIkDd/EVAO2GULgJvF13LUb7oPbtLQgGl1omf?= =?Windows-1252?Q?tKWxmPhJl0JhWGMHn4MhjXT+XKW/qBBc8D3qqLZ/cpmfNt1tJS7tENHk?= =?Windows-1252?Q?CY822jwcas0Cyr8Dw8ABgVb8SYSxQHrBN7vqw7vlplTGaeOwAUYMIjh/?= =?Windows-1252?Q?OtmynLJLJTdr8w3qwe+JeRN9PRdGMIkxclFXB/Tjs0WZfsYoq3RmtRpF?= =?Windows-1252?Q?jYRc/oMe74K1pAdZNGykq5ogiZ67yxu2YTiZNcr0idCmZST4DcpeQuhP?= =?Windows-1252?Q?vrruPW1dSVCyMNSCSEj49AQArxXun6uFtH9snffZlBKefFC4BGxRMckh?= =?Windows-1252?Q?OL5UhwHOYwvm4K9kKXyfnzu4u5NoiTDcQv17MUpS5ZrspVyhNEqHfsDl?= =?Windows-1252?Q?mObH/6/fNPLgtW144k4nNo5V9r207SnCn6YEhvcJxokKbf34/wkh4itc?= =?Windows-1252?Q?rqlUq7ah6gs5yM+0o/XxEWBTz+2/N9a7vgF0118GBn+XWJIr7ENLRtKA?= =?Windows-1252?Q?1InwC+Gms7RfKczYs7OlAARP4q5R2yOFdVUb89QSi5jF89aoDw7FfRWN?= =?Windows-1252?Q?vWhRkq631528xUHmEAz+LQ8/elRz1sjHmBQfv/PBDQVas2UoKWOFk9KL?= =?Windows-1252?Q?KAs9Kfcl1ZEidfhfZM9QjEc+ZElM0u3Nfqwew8mJyekdLCwdtzC9Kum5?= =?Windows-1252?Q?bg+JNUEaybAZrTuMhpYDuBxNtQWIBdy/gX80xUTfsiUxC1QEhb6RK7NU?= =?Windows-1252?Q?yKEhJ/paP2UNuqjPFE8X8dnjmT4Jxjptic0svCNDVLeihB8Iel9QOMP/?= =?Windows-1252?Q?0MDNwUh8DWCu0kXQW7ktJFvkWP81nf4qySr7MwcnWF2guP25nqktJYP0?= =?Windows-1252?Q?6R2L4x/DTpvouF72Y7mnzOK5NPx3fbCW3chsPk+N8JTJlJ3+AzxooflR?= =?Windows-1252?Q?40Lmwlgs+jmQDqkFoBwn2rJYiyDnZlsdR2ja81JMimPtbwO5+OgQ/lVN?= =?Windows-1252?Q?8PVm90nxJjL1NHO9OI0Guw1w3bQ=3D?= Content-Type: multipart/alternative; boundary="_000_FR2P281MB01384D72E72492140953C4258D9E9FR2P281MB0138DEUP_" MIME-Version: 1.0 X-OriginatorOrg: adorsys.de X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0138.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 4b2b37e1-b3eb-4c1d-ebfc-08d8d92ac445 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2021 01:14:57.6291 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5e2c5484-e522-479d-91ca-515d6e0ce228 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tVDcsfRYsVGbGPr5W+HAfFfWAdRfrgIg2i5mvhUFug1kaswW2tYCnR38+XndxWeJNroeQXfCBocZLt20DY2rKONaGyRYxOHT7yP7Rn6u+Us= X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRYP281MB0173 Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 01:15:09 -0000 --_000_FR2P281MB01384D72E72492140953C4258D9E9FR2P281MB0138DEUP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Justin, Adrian, in my initial contributions, I did refer to SSI just as a sample use case u= ser device generated token. We have a lot of example out there running with= Fido, EMV, electronic id cards, passports. Focus on the SSI philosophy might distract from the main issue: having user= device generated cryptograms. Nevertheless, SSI is a good framework to present the use case. Let distinguish between: - a verifiable credential (VC) and - a verifiable presentation (VP). A VC might be produced by an authority (let assume an AS) in a direct negot= iation between RO and AS. No involvement of the Client. I will call this a= direct interaction. The VP is produced by the RO and presented to the Client. No involvement of= the AS. This is also a direct interaction. The presentation of this original RO produced VP by a Client to an RS might= require a new presentation produced by the Client and warping the origina= l VP. I call this an embedded interaction. I am missing this one in GNAP. The =91Embedded=92 suggestion did not make it pass the initial discussion, = because we were unable to justify it legitime use to the OAuth legacy folks= . We have been using this interaction mode in the banking world for the las= t 20 years through diverse protocols. By adopting the embedded interaction, GNAP bridges the way to SSI. Please to not talk about =93embedding user password=94 a la =93password gra= nt=94. I am referring to allowing a client carry a cryptogram produced by t= he RO to the RS. If we define the producer of the Token to be an AS, the we will have to sho= w a mortal how to run the http based A-(Server) on the user device. Even if we narrow the definition of the AS to producing the VC and not the = VP, we still have a problem, as some VC might be produced by the user. In the EU we will be witnessing eIDAS certificates issued to user, allowing= them to produce their own VC, without the help of server based AS? Shall t= his make those VC producing applications running on the user device AS? The= n we will have to redefine AS. /Francis ________________________________ From: Francis Pouatcha Sent: Thursday, February 25, 2021 1:13 AM To: Justin Richer ; Adrian Gropper Cc: Francis Pouatcha ; Denis ; txauth g= nap Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI Justin, Adrian, in my initial contributions, I did refer to SSI just as a sample use case u= ser device generated token. We have a lot of example out there running with= Fido, EMV, electronic id cards, passports. Focus on the SSI philosophy might distract from the main issue: having user= device generated cryptograms. Nevertheless, SSI is a good framework to present the use case. Let distinguish between: - a verifiable credential (VC) and - a verifiable presentation (VP). A VC might be produced by an authority (let assume an AS) in a direct negot= iation between RO and AS. No involvement of the Client. I will call this a= direct interaction. The VP is produced by the RO and presented to the Client. No involvement of= the AS. This is also a direct interaction. The presentation of this original RO produced VP by a Client to an RS might= require a new presentation produced by the Client and warping the origina= l VP. I call this an embedded interaction. I am missing this one in GNAP. The =91Embedded=92 suggestion did not make it pass the initial discussion, = because we were unable to justify it legitime use to the OAuth legacy folks= . We have been using this interaction mode in the banking world for the las= t 20 years through diverse protocols. By adopting the embedded interaction, GNAP bridges the way to SSI. Please to not talk about =93embedding user password=94 a la =93password gra= nt=94. I am referring to allowing a client carry a cryptogram produced by t= he RO to the RS. If we define the producer of the Token to be an AS, the we will have to sho= w a mortal how to run the http based A-(Server) on the user device. Even if we narrow the definition of the AS to producing the VC and not the = VP, we still have a problem, as some VC might be produced by the user. In the EU we will be witnessing eIDAS certificates issued to user, allowing= them to produce their own VC, without the help of server based AS? Shall t= his make those VC producing applications running on the user device AS? The= n we will have to redefine AS. /Francis From: Justin Richer Date: Wednesday, February 24, 2021 at 1:58 PM To: Adrian Gropper Cc: Francis Pouatcha , Denis , txauth g= nap Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI +1 to this. In my opinion, building on anything other than HTTP right now i= s speculation, at best. And building an abstraction from zero-to-one concre= te manifestations is a recipe for disaster. Once a second thing comes along= , you inevitably realize that you put the abstraction points in the wrong p= lace and have in fact baked in a lot of assumptions about your base case in= to what was supposed to be an abstraction layer. Instead, if there=92s a desire to build out GNAP on top of other protocols,= then it should be :translated: to those protocols. This happened with OAut= h being built on top of COAP in ACE, without OAuth defining an abstraction = layer ahead of time. And I=92ll wager that if we had defined such a layer, = it would not have considered things like the multi-tiered client structures= that are in ACE, or the key distribution challenges in the IoT environment= . Abstractions can come after the fact to aid future translations, but tran= slation is nearly always more practical. But my point in starting this thread is that I think we can set up appropri= ate extension points for novel elements without throwing out the entire bas= e protocol, or creating something overly abstract. So I think we can keep t= he =93AS=94 component and the central HTTP-based protocol but have places w= here these other elements, like SSI wallets, can come in. I think we need t= o get away from the false conclusion that the SSI wallet has to :be: the AS= . Instead, I think the SSI wallet can feed information into an AS in order = for the AS to do its job. =97 Justin On Feb 24, 2021, at 12:47 PM, Adrian Gropper > wrote: It might help the GNAP scoping discussion relative to SSI if we consider tw= o separate domains: - Registration: The relationship between the RO and the RS prior to any GNA= P Client entering the picture, and - Authorization: The interaction protocols between the user agents of end u= sers and servers Fact: Only two SSI standards (VC and DID) are established enough for us to = reference in GNAP and they are both merely data models, not protocols. Neit= her of these data models is particularly concerned with delegation protocol= s although there is going to be some impact from things like multi-signatur= e schemes and filtering of capabilities. IMHO, GNAP as a delegation protocol standard cannot presume the success or = applicability of any SSI inspired protocols, including DIDcomm or Confident= ial Storage, that are still trying to figure out their relationship to HTTP= . Also, IMHO, SSI is not synonymous with protocols that presume a Holder as a= mandated intermediary store for any attribute that moves between an issuer= and a verifier. There are many, maybe most, use cases where SSI would be b= etter served by control of the attribute over actual possession of the attr= ibute. Adrian On Wed, Feb 24, 2021 at 12:09 PM Francis Pouatcha > wrote: Integrating GNAP and SSI requires a lot of fundamentals: * AS had their essence in the fact that human held devices were not abl= e to produce authorization sharable to client and RS * If the human held device can do the work, it is natural the momentum = will shift in that direction. This is what is happening with SSI. * Sharing all views of Adrian mention in this thread(no need to repeat)= . * But repeating the keyword: ZTA. Keeping custodian, server centered ar= chitectures under control is getting tougher as time goes by. In GNAP initial discussion, we walked through a lot of abstract diagram, th= at could have allowed production of authorization and authentication materi= al (token) by human held devices. The intention was inspired from SSI discu= ssions. IF Justin is asking to reconsider an integration of SSI, THEN we need to review the abstract protocol flows: * roles * entities * relationships We will have to start by taking the http protocol constraint out of the cha= rter. BTW * I agree with Justin: "The RS decides on how to consume a presented to= ken." * I agree with Denis: "AS plays no role and shall have no influence on = the RS decision on how to consume a token." THEN We must start by sharping the meaning of an AS (in the context of GNAP). Di= scussion might lead to a retirement of this term. As mortals might have a h= ard time considering a user held device a server. END IF Nevertheless, the transition from (http)-AS based token production to user = device-based token production will need some 10+ years to complete. Still a= lot of challenges around how to protect keys held on user devices against = damage, loss of device, malware, ransomware, social engineered attack. Can GNAP be the main vehicle for this transition? Maybe. Despite the (too) = strong reliance on the OAuth legacy (even if GNAP does not promise backward= compatibility to OAuth), an embedded interaction that allows the client to= carry the user device produced token to the resource server might pave way= for this transition. I campaigned for consideration of an embedded interac= tion in the initial conversation. I am not sure this was taken into account= . Still must find time to review the current draft. /Francis ________________________________ From: TXAuth > on b= ehalf of Denis > Sent: Tuesday, February 23, 2021 12:51 PM To: Justin Richer >; txauth gnap > Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI Hi Justin, See my comments between the lines. An important aspect in the discussion here, that I agree with, is that the = RS needs to be able to decide which AS it talks to. While I would agree with such a sentence in the OAuth WG, I don't believe = that this sentence is applicable in general in the context of GNAP. A RS does not need to "talk to" any AS. A RS decides which AS(s) it trusts = to issue access tokens that contains some set of privileges. But inherent in that is that it=92s not the user=92s decision, or the AS=92= s decision, it=92s the RS=92s decision who it will trust to get tokens from= . A RS does not necessarily need to trust all the access tokens issued by a g= iven AS, but only access tokens from a given AS that contain a given set of privileges. And no matter what our philosophy, at the end of the day the RS will always= have the choice of whether to trust an inbound request. Not exactly: the RS will apply the rules given by the RO. Which is why, to me, this really brings us to the question of what an AS pr= ovides. The AS gives the RS a token that the RS decides to trust, and that the RS can understand (either directly with something like JWT or = indirectly with something like introspection). But the AS also needs to decide what to put INTO that token. As a consequen= ce, the AS can get that information from any number of places. The information could be provided in a trusted way by the end user to the A= S =97 but this does NOT necessarily mean that the AS belongs to the user or is under their control. Basically, I think we=92re trying to hard to map the OAuth general-concept = of the RO having an account at the AS and logging in to it before authorizi= ng the request. I think that the call for =93every user to have their own AS=94 is such a h= uge non-starter in so many domains that it hampers the solution space if th= at=92s what we presume. It=92s up to the RS to decide who it trusts, not the end user and not the R= O. I think we should ALLOW it, and we can be clearer in GNAP that that=92s one= possible model, but not the only one, and not even the general one. The AS manages all of the information and interconnections needed to create= an access token that the RS will accept, and it is in charge of signaling = to the RS what that token=92s good for. I disagree: the AS is NOT in charge of signaling to the RS what that token= =92s good for. It is up to the RS to decide which privileges it will accept among all the privileges included into an access token. However, if the AS can learn through some other means that a specific ident= ified user has consented and provided appropriate information in a trusted = way, then THAT information can be baked into the token by the AS. =97 importantl= y, in a way that the RS=92s the AS protects can understand. I disagree: Trust relationships are not bilateral but only unilateral. An A= S does not need to have any specific prior relationship with a given RS. It is up to the RS(s) to decide which AS(s) it trust(s) and for which privi= leges. This last bit is where general opacity of tokens is important here. There= =92s a natural security boundary that arises from this model. What I=92m pr= oposing here is just that we=92re more explicit about what can be put INTO = that boundary. That=92s where I=92m seeing a lot of this innovation in the = SSI space fitting. You=92re not coming up with some universal access token = that the RS will accept, but you=92re able to provide universal claims and = artifacts that an AS can process and translate into a token the RS will acc= ept and do the right thing with. Your argumentation about token opacity is making the assumption that the AS= and the RS need to have a prior relationship before any access can take pl= ace. While this was valid with OAuth, this is no more valid in the context of GN= AP. The client should be able to inform the AS about the access token form= at(s) acceptable to the RS. Then the client may indicate to the AS these acceptable formats. If the RS = and the AS have an access token format in common, then the process may cont= inue. When only attributes (i.e. not rights) are being requested to an AS by the = client, the client does not need to disclose the identity of the RS to the = AS, which has the major advantage to prevent the AS to act as Big Brother. Note: this does not preclude the use of rights, in particular in the co= ntext of a single organization or enterprise. Denis =97 Justin On Feb 21, 2021, at 9:40 AM, Adrian Gropper > wrote: Hi Torsten, Thank you for raising all of these excellent points. I hope we can all answ= er them and maybe even add a section to the wiki. I'll start... You're right that OAuth deployments almost exclusively put the AS and RS in= the same domain. If OAuth were adequate to today's needs we probably would= not be here doing GNAP. Since OAuth, we have increasing privacy concerns a= nd security disasters. GDPR, for example, separates the role of a data cont= roller from a data processor and treats them as separate legal entities. To= oversimplify GDPR, the data processor is spared privacy responsibility and= cost. You are also right to mention open banking as a use-case. Open banking has = not adopted UMA 2.0 (on which I have worked for almost a decade) which is b= ased on OAuth. PSD2 and similar regulations do not tie the AS and RS to the= same security domain but they presume a narrow federation of licensed (and= regulated) ASs as payment processors for subjects to choose among. This ce= ntralization to regulated fiduciaries is a privacy trade-off that makes sen= se in banking. The fiduciary can be bonded so they can refund the money to = the subject in case of a security breach. This privacy-security tradeoff do= es not make sense in healthcare and other domains where the consequences of= a breach are not easily reversed. This thread is about aligning GNAP and SSI. SSI does not abide centralizati= on, censorship, or surveillance. If GNAP makes any assumptions that result = in either a tight coupling between AS and RS (surveillance) or even a feder= ated fiduciary (centralization) we will lose out on the benefits of progres= s in digital identity that is now driving a lot of public-sector initiative= s and starting to bleed over into private sector practices. Zero Trust Arch= itecture is an example and OAuth is not well suited for ZTA. As you said, "technically, the respective AS and RSs set up a trust relatio= nship and agreed on ways to share authorization and user data in order [to]= enable secure API access." This is where GNAP operates and we need to avoi= d _any_ restrictions on either the AS or the RS being self-sovereign. Examp= les of a self-sovereign RS could be a personal data store or an encrypted d= ata vault like the ones we work on in W3C/DIF. Any AS can be self-sovereign= if the subject controls all of the policies and these policies are not sha= red, in the same way a private key is never not shared. Continuing your quote: I read your ideas regarding self-sovereign ASs with great interest and got = some observations/questions: - A personal AS could certainly control access to a person=91s resources. I= assume the person=91s RSs would only accept access tokens signed by the RO= . Am I right? Yes, and. There is debate in various SSI WGs whether a RS such as an Encryp= ted Data Vault should respond to capabilities or tokens. Either way, the RO= is in control of the signature but a personal AS is a delegate of the RO (= either directly or via a mobile user agent). With capabilities such as ZCAP= -LD or biscuits, the token signature allows for filtered delegation. - Do you envision this AS to be able to control access to any kind of RS? H= ow is the AS supposed to know what authorization data this RS needs in orde= r to perform access control decisions? What data will be exchanged? Yes. The whole point, as far as I'm concerned, is to design human centered = standards. This is how W3C and IETF are different. Other SDOs tend to be op= erated for institutional benefit. A person-centered AS must work across ins= titutional domains. This, as you point out, brings up the problem of scope. Ontologies and data= models are, justifiably, domain-specific. I, for example, work around the = HL7 data model standards and APIs like FHIR that are controlled by healthca= re business interests. It's unreasonable to expect a general solution to th= e data model problem, although folks of the Linked Data persuasion might di= sagree. Every RS gets to decide what data models and ontologies it supports. These = decisions are public and sometimes standardized for the benefit of the clie= nts. A person's AS must read and maybe understand the RS data model in orde= r to issue tokens just like the client needs to do in order to make a reque= st to the AS. In our HIE of One Trustee project, we allow the self-sovereig= n subject to inherit AS policies from self-sovereign communities they choos= e and then modify the policies if they want. In this way, communities compe= te for members on the basis of policy bundles the same way churches compete= for congregants. - How would this person delegate access to her resources to someone else? There are two "persons" to consider. The RO delegates to an RQ. But the RQ,= in real life, is part of a team and often delegates to associates. With or= without capabilities, GNAP needs to deal with this reality that RO and RQ = user agents may be different from the client that actually presents a token= to the RS. Some of this difference between user agents and clients we may = be able to keep out of band. - Are you aware of deployments implementing this philosophy? Other than our HIE of One demonstration project in healthcare, no. We start= ed HIE of One before SSI in order to drive the transition from UMA to UMA 2= .0 and inform various healthcare regulatory priorities. We then jumped on S= SI immediately and added it to the UMA 2 AS we call Trustee. Now we are try= ing to align SSI and GNAP in order to enable human-centered protocols and z= ero-trust architecture. - What are the implications in terms of user experience? Right now, the human-centered user experience assumes a secure element and = web browser as user agents on a mobile device. Neither of these is readily = accessible as a server nor are they designed to accept code plug-ins that r= epresent the policies of an AS. One major exception is people adding advert= ising and surveillance blockers like EFF Privacy Badger to their browser. The user experience implications of having SSI data model standards and GNA= P protocol standards is that today's password managers (I have 250 RS relat= ionships in mine) will evolve to also control an AS agent. Just like I migh= t register a W3C DID with an RS instead of an email address, my policy mana= ger might display to me the token policies that will be applied by my AS to= the personal data I can control at that RS. In some cases, my AS will allow me to modify those policies just like the o= bnoxious cookie policy settings do today. The BIG difference with GNAP is t= hat I choose my AS separately from the RS so the dark patterns associated w= ith today's cookie policies experience are no longer possible. GNAP means t= he RS exposes an API rather than a UI. I've gone on far too long to address the issue of the AS as an identity pro= vider. It's fair to think of it that way. As it turns out, in the SSI Secur= e Data Storage WG, we are debating the difference between an Encrypted Data= Vault and an Identity Hub. As far as I'm concerned, the Identity Hub is mo= stly a GNAP AS. Join us on Thursdays at 4 PM ET https://lists.identity.foun= dation/g/sds-wg/wiki/Home Adrian On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt > wrote: Am 19.02.2021 um 23:50 schrieb Adrian Gropper >: ? I agree with the first two of Justin's responses but not the last one. It's confusing to think that there are more RS than AS. the OAuth deployments I=91m aware of typically have much more RSs than ASs.= Why? Because AS and a set of RSs belong to the same security domain (e.g. = a certain business) and it=92s the AS=92s responsibility to ensure secure a= nd convenient access to the APIs provided by this RSs. For example: there i= s a AS controlling access to a cloud, streaming, and messaging services of = the same business. In case of open banking, the bank=91s AS is (on behalf o= f the user) authorizing access to APIs for account information as well as p= ayment initiation and potentially other services. Technically, the respective AS and RSs set up a trust relationship and agre= ed on ways to share authorization and user data in order enable secure API = access. I read your ideas regarding self-sovereign ASs with great interest and got = some observations/questions: - A personal AS could certainly control access to a person=91s resources. I= assume the person=91s RSs would only accept access tokens signed by the RO= . Am I right? - Do you envision this AS to be able to control access to any kind of RS? H= ow is the AS supposed to know what authorization data this RS needs in orde= r to perform access control decisions? What data will be exchanged? - How would this person delegate access to her resources to someone else? - Are you aware of deployments implementing this philosophy? - What are the implications in terms of user experience? In my experience coupling between AS and RS is very tight. I have a hard ti= me to see how self-sovereign ASs would work. It feels like such an AS in th= e end is an identity provider of some sort, which brings me to what Justin = proposed. I would assume using SSI credentials to authenticate towards ASs = is feasible and might have value but I=91m skeptical about the AS part. best regards, Torsten. >From a human-centered (and hopefully IETF) perspective, each person might c= ontrol or specify a different AS for each of their personas or for each chi= ld or incompetent delegate of them as guardian. We're familiar with separat= e gmail addresses for each persona. ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial bitcoi= n wallet), or brokers (as in data brokers and surveillance capitalism). Any= RS that is willing to have a recurring relationship with a persona could a= ccept a GNAP AS endpoint instead of an email address. This is easiest using= HTTP, but GNAP need not exclude other RS / AS APIs and transports. Designi= ng around the uncensored specification of one's AS as a human right would g= reatly simplify many aspects of GNAP adoption. That said, GNAP should not ignore the RS business or jurisdictional reasons= to limit the authority of the AS. UMA 2.0 spent years dancing around this = issue with ideas like "cascading" AS and various centralized or federated A= S concepts. My conclusion is that any RS can always do whatever it wants an= d there's not much the authorization protocol can help with other than spec= ifying a notification endpoint so that an RS can warn (and seek confirmatio= n) or log various exceptions. This turns out to be, after a year of testimo= ny, the regulation that applies to HIPAA RS APIs in the US. For this reason= GNAP might include a notification protocol in the AS specification, or not= . I propose that embracing a self-sovereign agent is key to harmonizing the S= SI and GNAP standards. Adrian On Fri, Feb 19, 2021 at 2:30 PM Justin Richer > wrote: Tobias, thanks for the great observations. Some reactions inline below. On Feb 18, 2021, at 7:59 PM, Tobias Looker > wrote: Justin, I think this is a great and timely conversation to be having given the curr= ent interest around SSI and efforts like SIOP, I have been doing quite a bi= t of work in this space as of recent, so thought I'd add a few of the obser= vations that I've made. In my opinion SIOP was really a bucket for solving quite a few different pr= oblems, not just one. In particular I think its intent was to solve 3 major= ones: 1. Enabling portable identities 2. Solving the NASCAR problem 3. Exploring different deployment models for the provider To drill down briefly on these, note much of my terminology is OpenID based= due to SIOPs origin Enabling portable identities - In general today in the case of OpenID, the = end-users identity as understood by a relying party is scoped within the do= main of the provider. Which means if that provider goes out of business or = for whatever reason decides to no longer offer the same identity services t= o the End-User, their identity is essentially gone. Whilst there has been s= ome interesting related work from groups like MODRNA on solutions to combat= this like 'Account Porting', they often assume the old provider remains on= line and willing to facilitate in the account porting process so that the E= nd-User can migrate to a new provider. SIOP actually elected to do somethin= g different here by using cryptography, instead of the End-User identifier = being something like a GUID asserted within the domain of the provider, SIO= P defined this instead as a public key fingerprint associated to a private = key that's assumed to be under the control of the user. In doing so the ide= ntity itself becomes portable between providers by transferring the associa= ted private key. Now this approach does have drawbacks and arguably encoura= ges what many would refer to as bad cryptographic practise by not allowing = any way to do key rotation, however the idea was there. How GNAP can solve for this? By having flexibility around how the resource = owner / End-User is referred to by the Authorization server (e.g allow the = identifier to be something like a public key or a resolvable identifier to = public keys such as a DID) I personally think that GNAP should be a flexible :carrier: of identifiers = and other bits of identity information. This is the main reason we went wit= h the Subject Identifiers draft from SECEVENT: it=92s set up to talk about = a variety of different kinds of identifiers, all of them asserted in the co= ntext of the AS. If there=92s a definition for a DID URL or a JWK in the su= b_ids object structure, GNAP would be able to just use it directly alongsid= e every other format. I haven=92t seen those proposed yet, but it would be = easy to do and, in my mind, would be a better solution than the portable id= entifiers proposal that was recently brought up in the FAPI working group i= n OIDF. (A side note, but the main problem I have here is that it=92s pasti= ng semantics and formats onto a field where none existed before, and that= =92s rife for problems. Better to have a structure that takes that into acc= ount from the start, in my view.) Solving the NASCAR problem - One of those enduring problems in identity sys= tems, which I think is really about the three way negotiation going on betw= een the RP, the End-User and the Provider. SIOP's solution pushed for most = of the power in this decision making process to lie with the End-User, lett= ing them decide who they want as their provider rather than RP's providing = an enumeration of who they support via provider icons on their login page a= nd End-Users having to select from those options. It accomplished this via = using a custom URL scheme of `openid://` where the End-User would register = their chosen provider as a protocol handler for the `openid://` scheme. How= ever, again as a solution it's not without it's challenges, notably; only a= single registration at a time can be supported, the actual identity of the= provider remains blind to the RP until after the request is sent and it re= quires registration or some form of default handling (e.g when there is no = provider registered). How GNAP can solve for this? I actually don't think this is core to GNAP, t= here may be some considerations around discovery that are worth paying atte= ntion to but not much in the core protocol design. SIOP doesn=92t really solve the NASCAR issue since SIOP, by design, becomes= yet one more login option among many. I think GNAP can help this by enabli= ng user-directed provider discovery to kick off the process, but I agree th= at the core protocol doesn=92t really have much to say here, and shouldn=92= t. Exploring different deployment models for the provider - This is the most f= requently talked about aspect of SIOP and perhaps the most interesting to G= NAP. I like to think about the scope of this issue as designing to allow fo= r either a partially or fully distributed/decentralized provider, rather th= an a centralized one (e.g an HTTP based AuthZ server). As you noted this do= es come with its challenges many of which are technical in nature, i.e how = to appropriately address a decentralized provider and what protocols are us= ed to communicate with the provider. How GNAP can solve for this? I think that's what much of the discussion on = this thread will be about and whether there is a hybrid model where some re= sponsibility is still centrally administered like token issuance, while all= owing other aspects to occur in a more distributed manner. Ideally though I= 'd like to see consideration for a completely distributed model too. I agree that this seems to be the most interesting place for overlap. I don= =92t actually think the =93hybrid=94 approach centralizes things. Instead, = you can think of the RS as having an associated AS, and that AS accepting u= ser consent and claims at runtime from a variety of sources (wallets, VCs, = etc.). In this way, we aren=92t talking about a single AS in the world hand= ling all of these requests, we=92re talking about a distributed network of = AS=92s associated with an even more widely distributed set of RS=92s. SSI a= nd its associated technologies would help these =93local=94 AS=92s issue ac= cess tokens without the RO needing to have an account, or even necessarily = directly interacting with the AS. There=92s currently a technology gap ther= e, but my thoughts are that this is where the changes to the interaction mo= des section can really come to play. I think the notion of a non-HTTP AS is interesting, but I=92m not sure if t= hat=92s something GNAP ought to be solving for. I think that there=92s a de= ep value in building on top of HTTP for the core protocol, and not abstract= ing away concepts from it. Otherwise, you end up re-inventing layers, and y= ou get something like SOAP all over again. :) =97 Justin Thanks, [Mattr website] Tobias Looker Mattr +64 (0) 27 378 0461 tobias.looker@mattr.global [Mattr website] [Mattr on LinkedI= n] [Mattr on Twitter= ] [Mattr on Github]= This communication, including any attachments, is confidential. If you are = not the intended recipient, you should not read it - please contact me imme= diately, destroy it, and do not copy or use any part of this communication = or disclose anything about it. Thank you. Please note that this communicati= on does not designate an information system for the purposes of the Electro= nic Transactions Act 2002. On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault > wrote: Hi Justin, I agree that defining AS role primarily as a token issuer is a fruitful ide= a. Solving this problem well would also respond to the challenges discussed= previously on the list. Cheers Fabien Le mer. 17 f=E9vr. 2021 =E0 23:27, Justin Richer > a =E9crit : The last interim call had a lot of discussion on SSI technologies such as d= igital wallets, and how those fit with GNAP. I think it=92s worth continuin= g that conversation here on the list. There are a few issues in the tracker= that give some background, too: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 There=92s been a lot of interesting work recently in the OpenID Foundation = around using the Self-issued OP (SIOP) functionality to bootstrap an SSI st= yle login. This makes extensive use of the implicit flow and front channel = messaging, but minimization of the front channel for message passing is a k= ey design tenet of GNAP (so much so that it=92s included in our charter). I= nstead, GNAP has been built around an idea that everything starts the same = way: with an HTTP request to the AS. The idea of an on-device AS has been brought up a lot, and we need to consi= der if and how we want to deal with these kinds of use cases. The most obvi= ous way to address these would be to do some kind of clever off-HTTP hack l= ike SIOP, but keep in mind that even SIOP generally starts off with an HTTP= -based discovery call by the RP to make things work. My personal stance is that to do this, we need to re-evaluate our assumptio= ns about exactly what an AS does and what it needs to do those things. In O= Auth 2, it=92s assumed that the AS is the device that=92s authenticating th= e user, collecting consent, managing the client=92s registration, and creat= ing an access token based on whatever set of rights that are associated wit= h all of those things. In UMA, this is turned around a bit by letting the R= O present a bunch of nebulous =93claims=94 interactively, but still at the = AS. With both of these, a key aspect remains: the AS needs to gather necessary = information, and issue the access token (or identifiers/assertions). Becaus= e of how the protocol works, the client software now has a better opportuni= ty to present information to the AS, either directly in the request or by i= ntroducing the AS to another software component during the =93interaction= =94 phase. So, what if we think of the AS primarily as a =93token issuer=94= ? For example, if the client can present a verifiable credential (VC) that re= presents the end user, the AS can validate that VC and make an access token= on behalf of that user, without having the user log in or interact with th= e AS at all. This VC can contain whatever access rights the token needs to = represent, and the AS can translate that into an artifact that the downstre= am RS=92s can interpret, without having to see the original VC or the user = at all. The AS is still HTTP based, but all the essential security and righ= ts elements are provided by the wallet. In this way, we can expand on the p= rivacy-preserving aspects of OAuth and bridge the worlds of SSI and web API= s without violating the basic nature of either. Coming from the OAuth world, it feels weird to issue tokens like this, but = there=92s precedent for this kind of thing. Today, a there are a number of = service-based OAuth AS's that are told what claims need to get put into the= access token by some trusted component. All of this happens outside the OA= uth protocol. In GNAP, I think it makes sense to account for this kind of t= hing in how we define the protocol. That isn=92t to say all of these pieces= need to be defined in the core, but the base protocol ought to be able to = handle being extended in this direction as needed. I=92m really interested to hear other people=92s thoughts on how this could= come together. =97 Justin -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth This communication, including any attachments, is confidential. If you are = not the intended recipient, you should not read it - please contact me imme= diately, destroy it, and do not copy or use any part of this communication = or disclose anything about it. Thank you. Please note that this communicati= on does not designate an information system for the purposes of the Electro= nic Transactions Act 2002. -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- TXAuth mailing list TXAuth@ietf.org https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth= &source=3Dgmail-imap&ust=3D1614379828000000&usg=3DAOvVaw3avsUGQ48fo1OUQV0vy= yKd -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth --_000_FR2P281MB01384D72E72492140953C4258D9E9FR2P281MB0138DEUP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Justin, Adrian, 

     

    in my initial contributions, I did refer to SSI just as a sample use case user device generated token. We have a lot o= f example out there running with Fido, EMV, electronic id cards, passports.

     

    Focus on the SSI philosophy might distract from the main issue: having user device generated cryp= tograms.

     

    Nevertheless, SSI is a good framework to present the use case.

     

    Let distinguish between:

    - a verifiable credential (VC) and

    - a verifiable presentation (VP).

     

    A VC might be produced by an authority (let assume an AS) in a direct negot= iation between RO and AS. No involvement of the Client.  I will call t= his a direct interaction.

     

    The VP is produced by the RO and presented to the Client. No involvement of= the AS. This is also a direct interaction.

     

    The presentation of this original RO produced VP by a Client to an RS might= require a new presentation produced by the Client and warping the  or= iginal VP. I call this an embedded interaction. I am missing this one in GNAP.

     

    The =91Embedded=92 suggestion did not make it pass the initial discu= ssion, because we were unable to justify it legitime use to the OAuth legac= y folks. We have been using this interaction mode in the banking world for = the last 20 years through diverse protocols.

     

    By adopting the embedded interaction, GNAP bridges the way to SSI.

     

    Please to not talk about =93embedding user password=94 a la =93pa= ssword grant=94. I am referring to allowing a client carry a cryptogram= produced by the RO to the RS.

     

    If we define the producer of the Token to be an AS, the we will have to sho= w a mortal how to run the http based A-(Server) on the user device.

     

    Even if we narrow the definition of the AS to producing the VC and not the = VP, we still have a problem, as some VC might be produced by the user.=

     

    In the EU we will be witnessing eIDAS certificates issued to user, allowing= them to produce their own VC, without the help of server based AS? Shall t= his make those VC producing applications running on the user device AS? The= n we will have to redefine AS.

     

    /Francis

     



    From: Francis Pouatcha <= Francis.Pouatcha@adorsys.com>
    Sent: Thursday, February 25, 2021 1:13 AM
    To: Justin Richer <jricher@mit.edu>; Adrian Gropper <agropp= er@healthurl.com>
    Cc: Francis Pouatcha <fpo@adorsys.de>; Denis <denis.ietf@fr= ee.fr>; txauth gnap <txauth@ietf.org>
    Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI
     

    Justin, Adrian,

     

    in my initial contributions, I did refer to SSI just as a sample use case <= b>user device generated token. We have a lot of example out there runni= ng with Fido, EMV, electronic id cards, passports.

     

    Focus on the SSI philosophy might distract from the main issue: having u= ser device generated cryptograms.

     

    Nevertheless, SSI is a good framework to present the use case.

     

    Let distinguish between:

    - a verifiable credential (VC) and

    - a verifiable presentation (VP).

     

    A VC might be produced by an authority (let assume an AS) in a direct negot= iation between RO and AS. No involvement of the Client.  I will call t= his a direct interaction.

     

    The VP is produced by the RO and presented to the Client. No involvement of= the AS. This is also a direct interaction.

     

    The presentation of this original RO produced VP by a Client to an RS might= require a new presentation produced by the Client and warping the  or= iginal VP. I call this an embedded interaction. I am missing this one in GNAP.

     

    The =91Embedded=92 suggestion did not make it pass the initial discu= ssion, because we were unable to justify it legitime use to the OAuth legac= y folks. We have been using this interaction mode in the banking world for = the last 20 years through diverse protocols.

     

    By adopting the embedded interaction, GNAP bridges the way to SSI.

     

    Please to not talk about =93embedding user password=94 a la =93pa= ssword grant=94. I am referring to allowing a client carry a cryptogram= produced by the RO to the RS.

     

    If we define the producer of the Token to be an AS, the we will have to sho= w a mortal how to run the http based A-(Server) on the user device.

     

    Even if we narrow the definition of the AS to producing the VC and not the = VP, we still have a problem, as some VC might be produced by the user.

     

    In the EU we will be witnessing eIDAS certificates issued to user, allowing= them to produce their own VC, without the help of server based AS? Shall t= his make those VC producing applications running on the user device AS? The= n we will have to redefine AS.

     

    /Francis

     

     

    From: Justin Richer <jricher@mit.edu><= br> Date: Wednesday, February 24, 2021 at 1:58 PM
    To: Adrian Gropper <agropper@healthurl.com>
    Cc: Francis Pouatcha <fpo@adorsys.de>, Denis <denis.ietf@fr= ee.fr>, txauth gnap <txauth@ietf.org>
    Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI

    +1 to this. In my opinion, building on anything other than HTTP right now i= s speculation, at best. And building an abstraction from zero-to-one concre= te manifestations is a recipe for disaster. Once a second thing comes along= , you inevitably realize that you put the abstraction points in the wrong place and have in fact baked in a = lot of assumptions about your base case into what was supposed to be an abs= traction layer. 

     

    Instead, if there=92s a desire to build out GNAP on top of other protocols,= then it should be :translated: to those protocols. This happened with OAut= h being built on top of COAP in ACE, without OAuth defining an abstraction = layer ahead of time. And I=92ll wager that if we had defined such a layer, it would not have considered things l= ike the multi-tiered client structures that are in ACE, or the key distribu= tion challenges in the IoT environment. Abstractions can come after the fac= t to aid future translations, but translation is nearly always more practical. 

     

    But my point in starting this thread is that I think we can set up appropri= ate extension points for novel elements without throwing out the entire bas= e protocol, or creating something overly abstract. So I think we can keep t= he =93AS=94 component and the central HTTP-based protocol but have places where these other elements, like SSI w= allets, can come in. I think we need to get away from the false conclusion = that the SSI wallet has to :be: the AS. Instead, I think the SSI wallet can= feed information into an AS in order for the AS to do its job.

     

     =97 Justin



    On Feb 24, 2021, at 12:47 PM, Adrian Gropper <agropper@healthurl.com> wrote:

     

    It might help the GNAP scoping discussion relative to SSI if we consider tw= o separate domains: 

    - Registration: The relationship between the RO and the RS prior to = any GNAP Client entering the picture, and

    - Authorization: The interaction protocols between the user agents o= f end users and servers

     

    Fact: Only two SSI standards (VC and DID) are established enough for us to = reference in GNAP and they are both merely data models, not protocols. Neit= her of these data models is particularly concerned with delegation pro= tocols although there is going to be some impact from things like multi-signature schemes and filtering of capa= bilities.

     

    IMHO, GNAP as a delegation protocol standard cannot presume the succes= s or applicability of any SSI inspired protocols, including DIDcomm or Conf= idential Storage, that are still trying to figure out their relationship to= HTTP. 

     

    Also, IMHO, SSI is not synonymous with protocols that presume a Holder as a= mandated intermediary store for any attribute that moves between an issuer= and a verifier. There are many, maybe most, use cases where SSI would be b= etter served by control of the attribute over actual possession of the attribute.

     

    Adrian

     

     

     

    On Wed, Feb 24, 2021 at 12:09 PM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:<= /p>

    Integrating GNAP and SSI requires a lot of= fundamentals:

     

    • AS had their essence in the fact that huma= n held devices were not able to produce authorization sharable to client an= d RS
    • If the human held device can do the work, = it is natural the momentum will shift in that direction. This is what is ha= ppening with SSI.
    • Sharing all views of Adrian mention in thi= s thread(no need to repeat). 
    • But repeating the keyword: ZTA. Keeping cu= stodian, server centered architectures under control is getting tougher as = time goes by.

    In GNAP initial discussion, we walked thro= ugh a lot of abstract diagram, that could have allowed production of author= ization and authentication material (token) by human held devices. The inte= ntion was inspired from SSI discussions. 

     

    IF

      Justin is asking to reconsider an i= ntegration of SSI,

     

    THEN

    we need to review the abstract protocol fl= ows:

    • roles
    • entities
    • relationships

    We will have to start by taking the http p= rotocol constraint out of the charter.

     

    BTW

    • I agree with Justin: "The RS decides = on how to consume a presented token."
    • I agree with Denis: "AS plays no role= and shall have no influence on the RS decision on how to consume a token.&= quot;

     

    THEN

    We must start by sharping the meaning of a= n AS (in the context of GNAP). Discussion might lead to a retirement of thi= s term. As mortals might have a hard time considering a user held device a = server.

     

    END IF

     

     

    Nevertheless, the transition from (http)-A= S based token production to user device-based token production will need so= me 10+ years to complete. Still a lot of challenges around how to protect k= eys held on user devices against damage, loss of device, malware, ransomware, social engineered attack.

     

    Can GNAP be the main vehicle for this tran= sition? Maybe. Despite the (too) strong reliance on the OAuth legacy (even = if GNAP does not promise backward compatibility to OAuth), an embedded interaction that allows the client to carry the user device= produced token to the resource server might pave way for this transition. = I campaigned for consideration of an embedded interaction in the initial conversation. I am not sure this= was taken into account. Still must find time to review the current draft.<= /span>

     

     

    /Francis

     

     

    From: TXAuth <txauth-bounces@ietf.org> on behalf of Denis <denis.ietf@free.fr>=
    Sent: Tuesday, February 23, 2021 12:51 PM
    To: Justin Richer <jricher@mit.edu>; txauth gnap <txauth@ietf.org>
    Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI

     

    Hi  Justin,

     

    See my comments between the lines.

    An important aspect in the discussion here, that I agree with, is that the = RS needs to be able to decide which AS it talks to.

     While I would agree with such a sentence i= n the OAuth WG, I don't believe that this sentence is applicable in general= in the context of GNAP.
    A RS does not need to "talk to" any AS. A RS decides which AS(s) = it trusts to issue access tokens that contains some set of privileges.

    But inherent in that is that it=92s not the user=92s decision, or the AS=92= s decision, it=92s the RS=92s decision who it will trust to get tokens from= .

    A RS does not necessarily need to trust all the = access tokens issued by a given AS, but only access tokens from a given AS = that contain
    a given set of privileges.

    And no matter what our philosophy, at the end of the day the RS will always= have the choice of whether to trust an inbound request.

    Not exactly: the RS will apply the rules given b= y the RO.

    Which is why, to me, this really brings us to the question of what an AS pr= ovides. The AS gives the RS a token that the RS decides to trust,
    and that the RS can understand (either directly with something like JWT or = indirectly with something like introspection).
    But the AS also needs to decide what to put INTO that token. As a consequen= ce, the AS can get that information from any number of places.
    The information could be provided in a trusted way by the end user to the A= S =97 but this does NOT necessarily mean that the AS belongs
    to the user or is under their control. 

     

    Basically, I think we=92re trying to hard to map the OAuth general-concept = of the RO having an account at the AS and logging in to it before authorizi= ng the request.
    I think that the call for =93every user to have their own AS=94 is such a h= uge non-starter in so many domains that it hampers the solution space if th= at=92s what we presume.
    It=92s up to the RS to decide who it trusts, not the end user and not the R= O. 

     

    I think we should ALLOW it, and we can be clearer in GNAP that that=92s one= possible model, but not the only one, and not even the general one.
    The AS manages all of the information and interconnections needed to create= an access token that the RS will accept, and it is in charge of signaling = to the RS what that token=92s good for.

    I disagree: the AS is NOT in charge of signaling= to the RS what that token=92s good for. It is up to the RS to decide which= privileges it will accept
    among all the privileges included into an access token.

    However, if the AS can learn through some other means that a specific ident= ified user has consented and provided appropriate information in a trusted = way,
    then THAT information can be baked into the token by the AS. =97 importantl= y, in a way that the RS=92s the AS protects can understand.

    I disagree: Trust relationships are not bilatera= l but only unilateral. An AS does not need to have any specific prior relat= ionship with a given RS.
    It is up to the RS(s) to decide which AS(s) it trust(s) an= d for which privileges.

    This last bit is where general opacity of tokens is important= here. There=92s a natural security boundary that arises from this model. W= hat I=92m proposing here is just that we=92re more explicit about what can = be put INTO that boundary. That=92s where I=92m seeing a lot of this innovation in the SSI space fitting. You=92re n= ot coming up with some universal access token that the RS will accept, but = you=92re able to provide universal claims and artifacts that an AS can proc= ess and translate into a token the RS will accept and do the right thing with= .

    Your argumentation about token opacity is making= the assumption that the AS and the RS need to have a prior relationship be= fore any access can take place.
    While this was valid with OAuth, this is no more valid in the context of GN= AP.  The client should be able to inform the AS about the access token= format(s) acceptable to the RS.
    Then the client may indicate to the AS these acceptable formats. If the RS = and the AS have an access token format in common, then the process may cont= inue.

    When only attributes (i.e. not rights) are being= requested to an AS by the client, the client does not need to disclose the= identity of the RS to the AS,
    which has the major advantage to prevent the AS to act as Big Brother.

        Note: this does not pr= eclude the use of rights, in particular in the context of a single organiza= tion or enterprise.

    Denis

     

     =97 Justin



    On Feb 21, 2021, at 9:40 AM, Adrian Gropper <agropper@healthurl.com> wrote:

     

    Hi Torsten,

     

    Thank you for raising all of these excellent points. I hope we can all answ= er them and maybe even add a section to the wiki. I'll start...

     

    You're right that OAuth deployments almost exclusively put the AS and RS in= the same domain. If OAuth were adequate to today's needs we probably would= not be here doing GNAP. Since OAuth, we have increasing privacy concerns a= nd security disasters. GDPR, for example, separates the role of a data controller from a data processor and= treats them as separate legal entities. To oversimplify GDPR, the data pro= cessor is spared privacy responsibility and cost.

     

    You are also right to mention open banking as a use-case. Open banking has = not adopted UMA 2.0 (on which I have worked for almost a decade) which is b= ased on OAuth. PSD2 and similar regulations do not tie the AS and RS to the= same security domain but they presume a narrow federation of licensed (and regulated) ASs as payment processors = for subjects to choose among. This centralization to regulated fiduciaries = is a privacy trade-off that makes sense in banking. The fiduciary can be bo= nded so they can refund the money to the subject in case of a security breach. This privacy-security tradeof= f does not make sense in healthcare and other domains where the consequence= s of a breach are not easily reversed.

     

    This thread is about aligning GNAP and SSI. SSI does not abide centralizati= on, censorship, or surveillance. If GNAP makes any assumptions that result = in either a tight coupling between AS and RS (surveillance) or even a feder= ated fiduciary (centralization) we will lose out on the benefits of progress in digital identity that is n= ow driving a lot of public-sector initiatives and starting to bleed over in= to private sector practices. Zero Trust Architecture is an example and OAut= h is not well suited for ZTA.

     

    As you said, "technically, the respective AS and RSs set up a trust re= lationship and agreed on ways to share authorization and user data in order= [to] enable secure API access." This is where GNAP operates and we ne= ed to avoid _any_ restrictions on either the AS or the RS being self-sovereign. Examples of a self-sovereign RS could b= e a personal data store or an encrypted data vault like the ones we work on= in W3C/DIF. Any AS can be self-sovereign if the subject controls all of th= e policies and these policies are not shared, in the same way a private key is never not shared. 

     

    Continuing your quote:

    I read your ideas regarding self-sovereign ASs with great interest and got = some observations/questions:
    - A personal AS could certainly control access to a person=91s resources. I= assume the person=91s RSs would only accept access tokens signed by the RO= . Am I right?

    Yes, and. There is debate in various SSI WGs whether a RS such as an Encryp= ted Data Vault should respond to capabilities or tokens. Either way, the RO= is in control of the signature but a personal AS is a delegate of the RO (= either directly or via a mobile user agent). With capabilities such as ZCAP-LD or biscuits, the token= signature allows for filtered delegation.

     

    - Do you envision this AS to be able to control access to any kind of RS? H= ow is the AS supposed to know what authorization data this RS needs in orde= r to perform access control decisions? What data will be exchanged?

    Yes. The whole point, as far as I'm concerned, is to design human centered = standards. This is how W3C and IETF are different. Other SDOs tend to be op= erated for institutional benefit. A person-centered AS must work across ins= titutional domains. 

     

    This, as you point out, brings up the problem of scope. Ontologies and data= models are, justifiably, domain-specific. I, for example, work around the = HL7 data model standards and APIs like FHIR that are controlled by healthca= re business interests. It's unreasonable to expect a general solution to the data model problem, although folks of = the Linked Data persuasion might disagree.

     

    Every RS gets to decide what data models and ontologies it supports. These = decisions are public and sometimes standardized for the benefit of the clie= nts. A person's AS must read and maybe understand the RS data model in orde= r to issue tokens just like the client needs to do in order to make a request to the AS. In our HIE of One= Trustee project, we allow the self-sovereign subject to inherit AS policie= s from self-sovereign communities they choose and then modify the policies = if they want. In this way, communities compete for members on the basis of policy bundles the same way churches c= ompete for congregants.

     

    - How would this person delegate access to her resources to someone else?

    There are two "persons" to consider. The RO delegates to an RQ. B= ut the RQ, in real life, is part of a team and often delegates to associate= s. With or without capabilities, GNAP needs to deal with this reality that = RO and RQ user agents may be different from the client that actually presents a token to the RS. Some of this dif= ference between user agents and clients we may be able to keep out of band.=

     

    - Are you aware of deployments implementing this philosophy?

    Other than our HIE of One demonstration project in healthcare, no. We start= ed HIE of One before SSI in order to drive the transition from UMA to UMA 2= .0 and inform various healthcare regulatory priorities. We then jumped= on SSI immediately and added it to the UMA 2 AS we call Trustee. Now we are trying to align SSI and GNAP in order= to enable human-centered protocols and zero-trust architecture. 

     

    - What are the implications in terms of user experience?

    Right now, the human-centered user experience assumes a secure element and = web browser as user agents on a mobile device. Neither of these is readily = accessible as a server nor are they designed to accept code plug-ins t= hat represent the policies of an AS. One major exception is people adding advertising and surveillance blockers= like EFF Privacy Badger to their browser. 

     

    The user experience implications of having SSI data model standards and GNA= P protocol standards is that today's password managers (I have 250 RS relat= ionships in mine) will evolve to also control an AS agent. Just like I migh= t register a W3C DID with an RS instead of an email address, my policy manager might display to me the tok= en policies that will be applied by my AS to the personal data I can contro= l at that RS. 

     

    In some cases, my AS will allow me to modify those policies just like the o= bnoxious cookie policy settings do today. The BIG difference with GNAP is t= hat I choose my AS separately from the RS so the dark patterns associated w= ith today's cookie policies experience are no longer possible. GNAP means the RS exposes an API rather than a UI.=

     

    I've gone on far too long to address the issue of the AS as an identity pro= vider. It's fair to think of it that way. As it turns out, in the SSI Secur= e Data Storage WG, we are debating the difference between an Encrypted Data= Vault and an Identity Hub. As far as I'm concerned, the Identity Hub is mostly a GNAP AS. Join us on Thursda= ys at 4 PM ET https://lists.identity.foundation/g/sds-wg/wiki/= Home 

     

    Adrian

     

     

     

    On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt <torsten@lodderstedt.net> w= rote:

     



    Am 19.02.2021 um 23:50 schrieb Adrian Gropper <agropper@healthurl.com>:

    

    I agree with the first two of Justin's responses but not the last= one.

     

    It's confusing to think that there are more RS than AS.

     

    the OAuth deployments I=91m aware of typically have much more RSs than ASs.= Why? Because AS and a set of RSs belong to the same security domain (e.g. = a certain business) and it=92s the AS=92s responsibility to ensure secure a= nd convenient access to the APIs provided by this RSs. For example: there is a AS controlling access to a cloud, str= eaming, and messaging services of the same business. In case of open bankin= g, the bank=91s AS is (on behalf of the user) authorizing access to APIs fo= r account information as well as payment initiation and potentially other services. 

     

    Technically, the respective AS and RSs set up a trust relationship and agre= ed on ways to share authorization and user data in order enable secure API = access.

     

    I read your ideas regarding self-sovereign ASs with great interest and got = some observations/questions:

    - A personal AS could certainly control access to a person=91s resources. I= assume the person=91s RSs would only accept access tokens signed by the RO= . Am I right?

    - Do you envision this AS to be able to control access to any kind of RS? H= ow is the AS supposed to know what authorization data this RS needs in orde= r to perform access control decisions? What data will be exchanged?

    - How would this person delegate access to her resources to someone else?

    - Are you aware of deployments implementing this philosophy?

    - What are the implications in terms of user experience?

     

    In my experience coupling between AS and RS is very tight. I have a hard ti= me to see how self-sovereign ASs would work. It feels like such an AS in th= e end is an identity provider of some sort, which brings me to what Justin = proposed. I would assume using SSI credentials to authenticate towards ASs is feasible and might have value b= ut I=91m skeptical about the AS part.

     

    best regards,

    Torsten.



    >From a human-centered (and hopefully IETF) perspective, each person might c= ontrol or specify a different AS for each of their personas or for each chi= ld or incompetent delegate of them as guardian. We're familiar with separat= e gmail addresses for each persona.

     

    ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial bitcoi= n wallet), or brokers (as in data brokers and surveillance capitalism). Any= RS that is willing to have a recurring relationship with a persona could a= ccept a GNAP AS endpoint instead of an email address. This is easiest using HTTP, but GNAP need not exclude= other RS / AS APIs and transports. Designing around the uncensored specifi= cation of one's AS as a human right would greatly simplify many aspect= s of GNAP adoption.

     

    That said, GNAP should not ignore the RS business or jurisdictional re= asons to limit the authority of the AS. UMA 2.0 spent years dancing around = this issue with ideas like "cascading" AS and various centralized= or federated AS concepts. My conclusion is that any RS can always do whatever it wants and there's not much the authorizat= ion protocol can help with other than specifying a notification endpoint so= that an RS can warn (and seek confirmation) or log various exceptions. Thi= s turns out to be, after a year of testimony, the regulation that applies to HIPAA RS APIs in the US. For = this reason GNAP might include a notification protocol in the AS specificat= ion, or not.

     

    I propose that embracing a self-sovereign agent is key to harmonizing the S= SI and GNAP standards.

     

    Adrian

     

    On Fri, Feb 19, 2021 at 2:30 PM Justin Richer <jricher@mit.edu> wrote:

    Tobias, thanks for the great observations. Some reactions inline below.



    On Feb 18, 2021, at 7:59 PM, Tobias Looker <tobias.looker@mattr.global> wrot= e:

     

    Justin,

    I think this is a great and timely conversation to be having given the curr= ent interest around SSI and efforts like SIOP, I have been doing quite a bi= t of work in this space as of recent, so thought I'd add a few of the obser= vations that I've made.

    In my opinion SIOP was really a bucket for solving quite a few different pr= oblems, not just one. In particular I think its intent was to solve 3 major= ones:

    1. Enabling portable identities
    2. Solving the NASCAR problem
    3. Exploring different deployment models for the provider

    To drill down briefly on these, note much of my terminology is OpenID based= due to SIOPs origin 

    Enabling portable identities - In general today in the case of OpenI= D, the end-users identity as understood by a relying party is scoped within= the domain of the provider. Which means if that provider goes out of busin= ess or for whatever reason decides to no longer offer the same identity services to the End-User, their ident= ity is essentially gone. Whilst there has been some interesting related wor= k from groups like MODRNA on solutions to combat this like 'Account Porting= ', they often assume the old provider remains online and willing to facilitate in the account porting process so= that the End-User can migrate to a new provider. SIOP actually elected to = do something different here by using cryptography, instead of the End-User = identifier being something like a GUID asserted within the domain of the provider, SIOP defined this inste= ad as a public key fingerprint associated to a private key that's assumed t= o be under the control of the user. In doing so the identity itself becomes= portable between providers by transferring the associated private key. Now this approach does have drawbacks and argu= ably encourages what many would refer to as bad cryptographic practise by n= ot allowing any way to do key rotation, however the idea was there. 

     

    How GNAP can solve for this? By having flexibility around how the re= source owner / End-User is referred to by the Authorization server (e.g all= ow the identifier to be something like a public key or a resolvable identif= ier to public keys such as a DID)

     

    I personally think that GNAP should be a flexible :carrier: of identifiers = and other bits of identity information. This is the main reason we went wit= h the Subject Identifiers draft from SECEVENT: it=92s set up to talk about = a variety of different kinds of identifiers, all of them asserted in the context of the AS. If there=92s a definition f= or a DID URL or a JWK in the sub_ids object structure, GNAP would be able t= o just use it directly alongside every other format. I haven=92t seen those= proposed yet, but it would be easy to do and, in my mind, would be a better solution than the portable identi= fiers proposal that was recently brought up in the FAPI working group in OI= DF. (A side note, but the main problem I have here is that it=92s pasting s= emantics and formats onto a field where none existed before, and that=92s rife for problems. Better to have = a structure that takes that into account from the start, in my view.)




    Solving the NASCAR problem - One of those enduring problems in ident= ity systems, which I think is really about the three way negotiation going = on between the RP, the End-User and the Provider. SIOP's solution pushed fo= r most of the power in this decision making process to lie with the End-User, letting them decide who they want= as their provider rather than RP's providing an enumeration of who they su= pport via provider icons on their login page and End-Users having to select= from those options. It accomplished this via using a custom URL scheme of `openid://` where the End-User would= register their chosen provider as a protocol handler for the `openid://` s= cheme. However, again as a solution it's not without it's challenges, notab= ly; only a single registration at a time can be supported, the actual identity of the provider remains blind= to the RP until after the request is sent and it requires registration or = some form of default handling (e.g when there is no provider registered).
    How GNAP can solve for this? I actually don't think this is core to = GNAP, there may be some considerations around discovery that are worth payi= ng attention to but not much in the core protocol design.

     

    SIOP doesn=92t really solve the NASCAR issue since SIOP, by design, becomes= yet one more login option among many. I think GNAP can help this by enabli= ng user-directed provider discovery to kick off the process, but I agree th= at the core protocol doesn=92t really have much to say here, and shouldn=92t.



    Exploring different deployment models for the provider - This is the= most frequently talked about aspect of SIOP and perhaps the most interesti= ng to GNAP. I like to think about the scope of this issue as designing to a= llow for either a partially or fully distributed/decentralized provider, rather than a centralized one (e.g an = HTTP based AuthZ server). As you noted this does come with its challen= ges many of which are technical in nature, i.e how to appropriately address= a decentralized provider and what protocols are used to communicate with the provider.

    How GNAP can solve for this? I think that's what much of the di= scussion on this thread will be about and whether there is a hybrid model w= here some responsibility is still centrally administered like token issuanc= e, while allowing other aspects to occur in a more distributed manner. Ideally though I'd like to see consideration= for a completely distributed model too.

     

    I agree that this seems to be the most interesting place for overlap. I don= =92t actually think the =93hybrid=94 approach centralizes things. Instead, = you can think of the RS as having an associated AS, and that AS accepting u= ser consent and claims at runtime from a variety of sources (wallets, VCs, etc.). In this way, we aren=92t talkin= g about a single AS in the world handling all of these requests, we=92re ta= lking about a distributed network of AS=92s associated with an even more wi= dely distributed set of RS=92s. SSI and its associated technologies would help these =93local=94 AS=92s issue acce= ss tokens without the RO needing to have an account, or even necessarily di= rectly interacting with the AS. There=92s currently a technology gap there,= but my thoughts are that this is where the changes to the interaction modes section can really come to play. = ;

     

    I think the notion of a non-HTTP AS is interesting, but I=92m not sure if t= hat=92s something GNAP ought to be solving for. I think that there=92s a de= ep value in building on top of HTTP for the core protocol, and not abstract= ing away concepts from it. Otherwise, you end up re-inventing layers, and you get something like SOAP all over a= gain. :)

     

     =97 Justin



     

    Thanks,

    3D"Mattr=0A=

     

    Tobias Looker

    Mattr

    +64 (0) 27 378 0461
    tobias.looker= @mattr.global

    3D"Mattr

    3D"Matt=

    3D"Mattr=<= /span>


    This communication, including any at= tachments, is confidential. If you are not the intended recipient, you shou= ld not read it - please contact me immediately, destroy it, and do not copy= or use any part of this communication or disclose anything about it. Thank you. Please note that this communicat= ion does not designate an information system for the purposes of the Electr= onic Transactions Act 2002.

     

     

    On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault <fabien.imbault@gmail.com> wrot= e:

    Hi Justin,

     

    I agree that defining AS role primarily as a token issuer is a fruitful ide= a. Solving this problem well would also respond to the challenges discussed= previously on the list. 

     

    Cheers

    Fabien 

     

    Le mer. 17 f=E9vr. 2021 =E0 23:27, Justin Richer <jricher@mit.edu> a =E9crit :

    The last interim call had a lot of discussion on SSI technologies such as d= igital wallets, and how those fit with GNAP. I think it=92s worth continuin= g that conversation here on the list. There are a few issues in the tracker= that give some background, too:

     

     

    There=92s been a lot of interesting work recently in the OpenID Foundation = around using the Self-issued OP (SIOP) functionality to bootstrap an SSI st= yle login. This makes extensive use of the implicit flow and front channel = messaging, but minimization of the front channel for message passing is a key design tenet of GNAP (so much s= o that it=92s included in our charter). Instead, GNAP has been built around= an idea that everything starts the same way: with an HTTP request to the A= S. 

     

    The idea of an on-device AS has been brought up a lot, and we need to consi= der if and how we want to deal with these kinds of use cases. The most obvi= ous way to address these would be to do some kind of clever off-HTTP hack l= ike SIOP, but keep in mind that even SIOP generally starts off with an HTTP-based discovery call by the RP= to make things work.

     

    My personal stance is that to do this, we need to re-evaluate our assumptio= ns about exactly what an AS does and what it needs to do those things. In O= Auth 2, it=92s assumed that the AS is the device that=92s authenticating th= e user, collecting consent, managing the client=92s registration, and creating an access token based on whateve= r set of rights that are associated with all of those things. In UMA, this = is turned around a bit by letting the RO present a bunch of nebulous =93cla= ims=94 interactively, but still at the AS. 

     

    With both of these, a key aspect remains: the AS needs to gather necessary = information, and issue the access token (or identifiers/assertions). Becaus= e of how the protocol works, the client software now has a better opportuni= ty to present information to the AS, either directly in the request or by introducing the AS to another sof= tware component during the =93interaction=94 phase. So, what if we think of= the AS primarily as a =93token issuer=94? 

     

    For example, if the client can present a verifiable credential (VC) that re= presents the end user, the AS can validate that VC and make an access token= on behalf of that user, without having the user log in or interact with th= e AS at all. This VC can contain whatever access rights the token needs to represent, and the AS can transl= ate that into an artifact that the downstream RS=92s can interpret, without= having to see the original VC or the user at all. The AS is still HTTP bas= ed, but all the essential security and rights elements are provided by the wallet. In this way, we can expand= on the privacy-preserving aspects of OAuth and bridge the worlds of SSI an= d web APIs without violating the basic nature of either.

     

    Coming from the OAuth world, it feels weird to issue tokens like this, but = there=92s precedent for this kind of thing. Today, a there are a number of = service-based OAuth AS's that are told what claims need to get put into the= access token by some trusted component. All of this happens outside the OAuth protocol. In GNAP, I think it makes = sense to account for this kind of thing in how we define the protocol. That= isn=92t to say all of these pieces need to be defined in the core, but the= base protocol ought to be able to handle being extended in this direction as needed.

     

    I=92m really interested to hear other people=92s thoughts on how this could= come together.

     

     =97 Justin

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/= listinfo/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/= listinfo/txauth



    This communication, including any attachments, is confidential. If =
you are not the intended recipient, you should not read it - please contact=
 me immediately, destroy it, and do not copy or use any part of this commun=
ication or disclose anything about it. Thank you. Please note that this com=
munication does not designate an information system for the purposes of the=
 Electronic Transactions Act 2002.<=
/span>

     

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/= listinfo/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.google.com/url?q= =3Dhttps://www.ietf.org/mailman/listinfo/txauth&source=3Dgmail-imap&= ;ust=3D1614379828000000&usg=3DAOvVaw3avsUGQ48fo1OUQV0vyyKd

     



     

    --
    TXAuth mailing list
    TXAuth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth

     

    --_000_FR2P281MB01384D72E72492140953C4258D9E9FR2P281MB0138DEUP_-- From nobody Wed Feb 24 18:10:09 2021 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 329C23A0C74 for ; Wed, 24 Feb 2021 18:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 MfITp4gcUY7r for ; Wed, 24 Feb 2021 18:10:01 -0800 (PST) Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) (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 8F8313A0C6D for ; Wed, 24 Feb 2021 18:10:01 -0800 (PST) Received: by mail-vk1-f171.google.com with SMTP id d13so867193vko.4 for ; Wed, 24 Feb 2021 18:10:01 -0800 (PST) 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=LScyUAu//gjTtyPxD7cYL81IVAkvki2GH51BBGeZWtI=; b=nFLX6b4AJNhf9CzL03VgjXNS4SJk0Cf+HHb717oZXFZRye+4uKU10LB1oBY8t07yVM uftClF/M1BHsyGp4l8d6RAO1pgMStmXJaDkQymPktujLbGA4NWftLe1TYNwLjfOTLHHN sKoa42GyqHVMJGdL9S8h+9q2baKGm5zx9I7EbOhPqV0G3ySo0n54pdcP90ryOEvjmaJM RJrwQxHnR13G+5qrJS7HBmqwbMPhThxZCeO/+WsUsqZN6RAMDt7yHwqUB4PWJKGNFwA1 Sa0b4SMvnU0atGQgvhKfiPuCWLumLF0DzjVehkVSbazLDH1iI7bXrsJWx7H9oT94b8y3 qovQ== X-Gm-Message-State: AOAM530zbjvndz05LPRC1B43tCvOGsh+y+zpu0GRAnf1ayD25cG9uTYx 2T4zyNcTPvgW8S8FbDuzO/EkAh/kLtcfznR8f0I= X-Google-Smtp-Source: ABdhPJw4l8HvfmliDcvEqXTPBnLd8WG1B689VUeda8ggPjoi35qkk9n3edzD8+eKXi4YzG/ON0+rT42tySbhY6rcxgY= X-Received: by 2002:a1f:9692:: with SMTP id y140mr344501vkd.20.1614218999988; Wed, 24 Feb 2021 18:09:59 -0800 (PST) MIME-Version: 1.0 References: <4EAA60A4-4800-400F-A70A-F7B7F1A6CB0A@mit.edu> <73cd4e8b-c843-ab87-c640-eea763b6002a@free.fr> <34DD2820-06F8-4226-A987-DF6F1105B87D@mit.edu> In-Reply-To: From: Adrian Gropper Date: Wed, 24 Feb 2021 21:09:47 -0500 Message-ID: To: Francis Pouatcha Cc: Justin Richer , Denis , txauth gnap Content-Type: multipart/alternative; boundary="0000000000001587f005bc1fa6e1" Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 02:10:09 -0000 --0000000000001587f005bc1fa6e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Francis, I deeply want to understand what use-cases GNAP may be missing but I'm having trouble understanding your requirement and don't have the benefit of banking world experience. It doesn't matter to me whether GNAP is missing a use-case related to SSI or not. I just want to understand any limitations we might be building into GNAP 1.0 I hope some of this helps us come to a common vocabulary... 1. I think in terms of delegation. The GNAP AS is a delegate of the RO. The RO (or RQ) uses a user agent to interact with the AS. This user-agent could be a web browser or a mobile app. I assume that users can choose user agents that include a HSM such as a FIDO2 or SIM card and I hope that's encouraged but if an AS wants to deal with username / password, I would not prohibit that. 2. The RS is another kind of delegation. As with the AS, the RO can approach the RS directly with a user agent and exercise their privilege of specifying an AS as their delegate if the RS offers that feature. If the RS does not offer that feature to the RO, then I don't think GNAP is very relevant. If the RS restricts the RO's choice of ASs to a list or federation then GNAP still applies but in this case SSI principles are likely being trampled. 3. The RQ relationship with the RS is _not_ delegation. It is authorization. This is true whether the RQ happens to be the RO or a separate party. I consider the RQ - RS relationship to be mediated by a Client, not a user agent. In some cases, the RQ user agent is also their client but I hope that GNAP never makes this assumption. In other words, the party that interacts with the AS may not be the same as the party that interacts with the RS because we want to encourage the ability for the RQ to delegate to another end user and the client of that end user. This is critical to effective workflows in the real world. 4. This raises issues around the responsibility of the RS to honor their commitment as a delegate of the RO while also supporting legitimate privacy interests of the RQ or the delegate of the RQ as well as jurisdictional mandates that could force the RS to disregard a valid authorization token ("export restriction") or accept an authorization token that was not rooted in trust of the AS ("break the glass"). To summarize, GNAP _should_ deal with delegation as distinct from authorization. Some aspects of delegation _may_ be out of band for GNAP because GNAP is an authorization protocol. The case of an authorization token being part of a delegation chain _should not_ be precluded by GNAP. The transport and API between a user agent and an AS and a user agent and an RS are not a matter of authorization and, although critically important, might not need to be specified by GNAP. I've not used any SSI terminology above. Can you help me understand what SSI, banking, or other use-cases I may be missing? - Adrian On Wed, Feb 24, 2021 at 8:15 PM Francis Pouatcha wrote: > Justin, Adrian, > > > > in my initial contributions, I did refer to SSI just as a sample use case= *user > device generated* token. We have a lot of example out there running with > Fido, EMV, electronic id cards, passports. > > > > Focus on the SSI philosophy might distract from the main issue: having *u= ser > device generated cryptograms*. > > > > Nevertheless, SSI is a good framework to present the use case. > > > > Let distinguish between: > > - a verifiable credential (VC) and > > - a verifiable presentation (VP). > > > > A VC might be produced by an authority (let assume an AS) in a direct > negotiation between RO and AS. No involvement of the Client. I will call > this a direct interaction. > > > > The VP is produced by the RO and presented to the Client. No involvement > of the AS. This is also a direct interaction. > > > > The presentation of this original RO produced VP by a Client to an RS > might require a new presentation produced by the Client and warping the > original VP. I call this an *embedded interaction*. I am missing this > one in GNAP. > > > > The =E2=80=98*Embedded*=E2=80=99 suggestion did not make it pass the init= ial discussion, > because we were unable to justify it legitime use to the OAuth legacy > folks. We have been using this interaction mode in the banking world for > the last 20 years through diverse protocols. > > > > By adopting the embedded interaction, GNAP bridges the way to SSI. > > > > Please to not talk about =E2=80=9C*embedding user password*=E2=80=9D a la= =E2=80=9C*password > grant*=E2=80=9D. I am referring to allowing a client carry a cryptogram p= roduced > by the RO to the RS. > > > > If we define the producer of the Token to be an AS, the we will have to > show a mortal how to run the http based A-(Server) on the user device. > > > > Even if we narrow the definition of the AS to producing the VC and not th= e > VP, we still have a problem, as some VC might be produced by the user. > > > > In the EU we will be witnessing eIDAS certificates issued to user, > allowing them to produce their own VC, without the help of server based A= S? > Shall this make those VC producing applications running on the user devic= e > AS? Then we will have to redefine AS. > > > > /Francis > > > > > ------------------------------ > *From:* Francis Pouatcha > *Sent:* Thursday, February 25, 2021 1:13 AM > *To:* Justin Richer ; Adrian Gropper < > agropper@healthurl.com> > *Cc:* Francis Pouatcha ; Denis ; > txauth gnap > *Subject:* Re: [GNAP] Integrating a GNAP AS with wallets and SSI > > > Justin, Adrian, > > > > in my initial contributions, I did refer to SSI just as a sample use case= *user > device generated* token. We have a lot of example out there running with > Fido, EMV, electronic id cards, passports. > > > > Focus on the SSI philosophy might distract from the main issue: having *u= ser > device generated cryptograms*. > > > > Nevertheless, SSI is a good framework to present the use case. > > > > Let distinguish between: > > - a verifiable credential (VC) and > > - a verifiable presentation (VP). > > > > A VC might be produced by an authority (let assume an AS) in a direct > negotiation between RO and AS. No involvement of the Client. I will call > this a direct interaction. > > > > The VP is produced by the RO and presented to the Client. No involvement > of the AS. This is also a direct interaction. > > > > The presentation of this original RO produced VP by a Client to an RS > might require a new presentation produced by the Client and warping the > original VP. I call this an *embedded interaction*. I am missing this > one in GNAP. > > > > The =E2=80=98*Embedded*=E2=80=99 suggestion did not make it pass the init= ial discussion, > because we were unable to justify it legitime use to the OAuth legacy > folks. We have been using this interaction mode in the banking world for > the last 20 years through diverse protocols. > > > > By adopting the embedded interaction, GNAP bridges the way to SSI. > > > > Please to not talk about =E2=80=9C*embedding user password*=E2=80=9D a la= =E2=80=9C*password > grant*=E2=80=9D. I am referring to allowing a client carry a cryptogram p= roduced > by the RO to the RS. > > > > If we define the producer of the Token to be an AS, the we will have to > show a mortal how to run the http based A-(Server) on the user device. > > > > Even if we narrow the definition of the AS to producing the VC and not th= e > VP, we still have a problem, as some VC might be produced by the user. > > > > In the EU we will be witnessing eIDAS certificates issued to user, > allowing them to produce their own VC, without the help of server based A= S? > Shall this make those VC producing applications running on the user devic= e > AS? Then we will have to redefine AS. > > > > /Francis > > > > > > *From: *Justin Richer > *Date: *Wednesday, February 24, 2021 at 1:58 PM > *To: *Adrian Gropper > *Cc: *Francis Pouatcha , Denis , > txauth gnap > *Subject: *Re: [GNAP] Integrating a GNAP AS with wallets and SSI > > +1 to this. In my opinion, building on anything other than HTTP right now > is speculation, at best. And building an abstraction from zero-to-one > concrete manifestations is a recipe for disaster. Once a second thing com= es > along, you inevitably realize that you put the abstraction points in the > wrong place and have in fact baked in a lot of assumptions about your bas= e > case into what was supposed to be an abstraction layer. > > > > Instead, if there=E2=80=99s a desire to build out GNAP on top of other pr= otocols, > then it should be :translated: to those protocols. This happened with OAu= th > being built on top of COAP in ACE, without OAuth defining an abstraction > layer ahead of time. And I=E2=80=99ll wager that if we had defined such a= layer, it > would not have considered things like the multi-tiered client structures > that are in ACE, or the key distribution challenges in the IoT environmen= t. > Abstractions can come after the fact to aid future translations, but > translation is nearly always more practical. > > > > But my point in starting this thread is that I think we can set up > appropriate extension points for novel elements without throwing out the > entire base protocol, or creating something overly abstract. So I think w= e > can keep the =E2=80=9CAS=E2=80=9D component and the central HTTP-based pr= otocol but have > places where these other elements, like SSI wallets, can come in. I think > we need to get away from the false conclusion that the SSI wallet has to > :be: the AS. Instead, I think the SSI wallet can feed information into an > AS in order for the AS to do its job. > > > > =E2=80=94 Justin > > > > On Feb 24, 2021, at 12:47 PM, Adrian Gropper > wrote: > > > > It might help the GNAP scoping discussion relative to SSI if we consider > two separate domains: > > - *Registration:* The relationship between the RO and the RS prior to any > GNAP Client entering the picture, and > > - *Authorization:* The interaction protocols between the user agents of > end users and servers > > > > Fact: Only two SSI standards (VC and DID) are established enough for us t= o > reference in GNAP and they are both merely data models, not protocols. > Neither of these data models is particularly concerned with delegation > protocols although there is going to be some impact from things like > multi-signature schemes and filtering of capabilities. > > > > IMHO, GNAP as a delegation protocol standard cannot presume the success o= r > applicability of any SSI inspired protocols, including DIDcomm or > Confidential Storage, that are still trying to figure out their > relationship to HTTP. > > > > Also, IMHO, SSI is not synonymous with protocols that presume a Holder as > a mandated intermediary store for any attribute that moves between an > issuer and a verifier. There are many, maybe most, use cases where SSI > would be better served by control of the attribute over actual possession > of the attribute. > > > > Adrian > > > > > > > > On Wed, Feb 24, 2021 at 12:09 PM Francis Pouatcha 40adorsys.de@dmarc.ietf.org> wrote: > > Integrating GNAP and SSI requires a lot of fundamentals: > > > > - AS had their essence in the fact that human held devices were not > able to produce authorization sharable to client and RS > - If the human held device can do the work, it is natural the momentum > will shift in that direction. This is what is happening with SSI. > - Sharing all views of Adrian mention in this thread(no need to > repeat). > - But repeating the keyword: ZTA. Keeping custodian, server centered > architectures under control is getting tougher as time goes by. > > In GNAP initial discussion, we walked through a lot of abstract diagram, > that could have allowed production of authorization and authentication > material (token) by human held devices. The intention was inspired from S= SI > discussions. > > > > IF > > Justin is asking to reconsider an integration of SSI, > > > > THEN > > we need to review the abstract protocol flows: > > - roles > - entities > - relationships > > We will have to start by taking the http protocol constraint out of the > charter. > > > > BTW > > - I agree with Justin: "The RS decides on how to consume a presented > token." > - I agree with Denis: "AS plays no role and shall have no influence on > the RS decision on how to consume a token." > > > > THEN > > We must start by sharping the meaning of an AS (in the context of GNAP). > Discussion might lead to a retirement of this term. As mortals might have= a > hard time considering a user held device a server. > > > > END IF > > > > > > Nevertheless, the transition from (http)-AS based token production to use= r > device-based token production will need some 10+ years to complete. Still= a > lot of challenges around how to protect keys held on user devices against > damage, loss of device, malware, ransomware, social engineered attack. > > > > Can GNAP be the main vehicle for this transition? Maybe. Despite the (too= ) > strong reliance on the OAuth legacy (even if GNAP does not promise backwa= rd > compatibility to OAuth), an *embedded* interaction that allows the client > to carry the user device produced token to the resource server might pave > way for this transition. I campaigned for consideration of an *embedded > interaction* in the initial conversation. I am not sure this was taken > into account. Still must find time to review the current draft. > > > > > > /Francis > > > > > ------------------------------ > > *From:* TXAuth on behalf of Denis < > denis.ietf@free.fr> > *Sent:* Tuesday, February 23, 2021 12:51 PM > *To:* Justin Richer ; txauth gnap > *Subject:* Re: [GNAP] Integrating a GNAP AS with wallets and SSI > > > > Hi Justin, > > > > See my comments between the lines. > > An important aspect in the discussion here, that I agree with, is that th= e > RS needs to be able to decide *which AS it talks to*. > > While I would agree with such a sentence in the OAuth WG, I don't believ= e > that this sentence is applicable in general in the context of GNAP. > A RS does not need to "talk to" any AS. A RS decides which AS(s) it trust= s > to issue access tokens *that contains some set of privileges*. > > But inherent in that is that it=E2=80=99s not the user=E2=80=99s decision= , or the AS=E2=80=99s > decision, it=E2=80=99s the RS=E2=80=99s decision who it will trust to get= tokens from. > > A RS does not necessarily need to trust all the access tokens issued by a > given AS, but only access tokens from a given AS that contain > *a given set of privileges*. > > And no matter what our philosophy, at the end of the day the RS will > always have the choice of whether to trust an inbound request. > > Not exactly: the RS will apply the rules given by the RO. > > Which is why, to me, this really brings us to the question of what an AS > provides. The AS gives the RS a token that the RS decides to trust, > and that the RS can understand (either directly with something like JWT o= r > indirectly with something like introspection). > But the AS also needs to decide what to put INTO that token. As a > consequence, the AS can get that information from any number of places. > The information could be provided in a trusted way by the end user to the > AS =E2=80=94 but this does NOT necessarily mean that the AS belongs > to the user or is under their control. > > > > Basically, I think we=E2=80=99re trying to hard to map the OAuth general-= concept > of the RO having an account at the AS and logging in to it before > authorizing the request. > I think that the call for =E2=80=9Cevery user to have their own AS=E2=80= =9D is such a huge > non-starter in so many domains that it hampers the solution space if that= =E2=80=99s > what we presume. > It=E2=80=99s up to the RS to decide who it trusts, not the end user and n= ot the > RO. > > > > I think we should ALLOW it, and we can be clearer in GNAP that that=E2=80= =99s one > possible model, but not the only one, and not even the general one. > The AS manages all of the information and interconnections needed to > create an access token that the RS will accept, and it is in charge of > signaling to the RS what that token=E2=80=99s good for. > > I disagree: the AS is NOT in charge of signaling to the RS what that > token=E2=80=99s good for. It is up to the RS to decide which privileges i= t will > accept > among all the privileges included into an access token. > > However, if the AS can learn through some other means that a specific > identified user has consented and provided appropriate information in a > trusted way, > then THAT information can be baked into the token by the AS. =E2=80=94 im= portantly,* > in a way that the RS=E2=80=99s the AS protects can understand*. > > I disagree: Trust relationships are not bilateral but only unilateral. An > AS does not need to have any specific prior relationship with a given RS. > It is up to the RS(s) to decide which AS*(s)* it trust(s) *and for which > privileges*. > > This last bit is where general *opacity of tokens* is important here. > There=E2=80=99s a natural security boundary that arises from this model. = What I=E2=80=99m > proposing here is just that we=E2=80=99re more explicit about what can be= put INTO > that boundary. That=E2=80=99s where I=E2=80=99m seeing a lot of this inno= vation in the SSI > space fitting. You=E2=80=99re not coming up with some universal access to= ken that > the RS will accept, but you=E2=80=99re able to provide universal claims a= nd > artifacts that an AS can process and *translate into a token the RS will > accept and do the right thing with*. > > Your argumentation about token opacity is making the assumption that the > AS and the RS need to have a prior relationship before any access can tak= e > place. > While this was valid with OAuth, this is no more valid in the context of > GNAP. The client should be able to inform the AS about the access token > format(s) acceptable to the RS. > Then the client may indicate to the AS these acceptable formats. If the R= S > and the AS have an access token format in common, then the process may > continue. > > When only attributes (i.e. not rights) are being requested to an AS by th= e > client, the client does not need to disclose the identity of the RS to th= e > AS, > which has the major advantage to prevent the AS to act as Big Brother. > > *Note*: this does not preclude the use of rights, in particular in > the context of a single organization or enterprise. > > Denis > > > > =E2=80=94 Justin > > > > On Feb 21, 2021, at 9:40 AM, Adrian Gropper > wrote: > > > > Hi Torsten, > > > > Thank you for raising all of these excellent points. I hope we can all > answer them and maybe even add a section to the wiki. I'll start... > > > > You're right that OAuth deployments almost exclusively put the AS and RS > in the same domain. If OAuth were adequate to today's needs we probably > would not be here doing GNAP. Since OAuth, we have increasing privacy > concerns and security disasters. GDPR, for example, separates the role of= a > data controller from a data processor and treats them as separate legal > entities. To oversimplify GDPR, the data processor is spared privacy > responsibility and cost. > > > > You are also right to mention open banking as a use-case. Open banking ha= s > not adopted UMA 2.0 (on which I have worked for almost a decade) which is > based on OAuth. PSD2 and similar regulations do not tie the AS and RS to > the same security domain but they presume a narrow federation of licensed > (and regulated) ASs as payment processors for subjects to choose among. > This centralization to regulated fiduciaries is a privacy trade-off that > makes sense in banking. The fiduciary can be bonded so they can refund th= e > money to the subject in case of a security breach. This privacy-security > tradeoff does not make sense in healthcare and other domains where the > consequences of a breach are not easily reversed. > > > > This thread is about aligning GNAP and SSI. SSI does not abide > centralization, censorship, or surveillance. If GNAP makes any assumption= s > that result in either a tight coupling between AS and RS (surveillance) o= r > even a federated fiduciary (centralization) we will lose out on the > benefits of progress in digital identity that is now driving a lot of > public-sector initiatives and starting to bleed over into private sector > practices. Zero Trust Architecture is an example and OAuth is not well > suited for ZTA. > > > > As you said, "technically, the respective AS and RSs set up a trust > relationship and agreed on ways to share authorization and user data in > order [to] enable secure API access." This is where GNAP operates and we > need to avoid _any_ restrictions on either the AS or the RS being > self-sovereign. Examples of a self-sovereign RS could be a personal data > store or an encrypted data vault like the ones we work on in W3C/DIF. Any > AS can be self-sovereign if the subject controls all of the policies and > these policies are not shared, in the same way a private key is never not > shared. > > > > Continuing your quote: > > I read your ideas regarding self-sovereign ASs with great interest and go= t > some observations/questions: > - A personal AS could certainly control access to a person=E2=80=98s reso= urces. I > assume the person=E2=80=98s RSs would only accept access tokens signed by= the RO. > Am I right? > > Yes, and. There is debate in various SSI WGs whether a RS such as an > Encrypted Data Vault should respond to capabilities or tokens. Either way= , > the RO is in control of the signature but a personal AS is a delegate of > the RO (either directly or via a mobile user agent). With capabilities su= ch > as ZCAP-LD or biscuits, the token signature allows for filtered delegatio= n. > > > > - Do you envision this AS to be able to control access to any kind of RS? > How is the AS supposed to know what authorization data this RS needs in > order to perform access control decisions? What data will be exchanged? > > Yes. The whole point, as far as I'm concerned, is to design human centere= d > standards. This is how W3C and IETF are different. Other SDOs tend to be > operated for institutional benefit. A person-centered AS must work across > institutional domains. > > > > This, as you point out, brings up the problem of scope. Ontologies and > data models are, justifiably, domain-specific. I, for example, work aroun= d > the HL7 data model standards and APIs like FHIR that are controlled by > healthcare business interests. It's unreasonable to expect a general > solution to the data model problem, although folks of the Linked Data > persuasion might disagree. > > > > Every RS gets to decide what data models and ontologies it supports. Thes= e > decisions are public and sometimes standardized for the benefit of the > clients. A person's AS must read and maybe understand the RS data model i= n > order to issue tokens just like the client needs to do in order to make a > request to the AS. In our HIE of One Trustee project, we allow the > self-sovereign subject to inherit AS policies from self-sovereign > communities they choose and then modify the policies if they want. In thi= s > way, communities compete for members on the basis of policy bundles the > same way churches compete for congregants. > > > > - How would this person delegate access to her resources to someone else? > > There are two "persons" to consider. The RO delegates to an RQ. But the > RQ, in real life, is part of a team and often delegates to associates. Wi= th > or without capabilities, GNAP needs to deal with this reality that RO and > RQ user agents may be different from the client that actually presents a > token to the RS. Some of this difference between user agents and clients = we > may be able to keep out of band. > > > > - Are you aware of deployments implementing this philosophy? > > Other than our HIE of One demonstration project in healthcare, no. We > started HIE of One before SSI in order to drive the transition from UMA t= o > UMA 2.0 and inform various healthcare regulatory priorities. We then jump= ed > on SSI immediately and added it to the UMA 2 AS we call Trustee. Now we a= re > trying to align SSI and GNAP in order to enable human-centered protocols > and zero-trust architecture. > > > > - What are the implications in terms of user experience? > > Right now, the human-centered user experience assumes a secure element an= d > web browser as user agents on a mobile device. Neither of these is readil= y > accessible as a server nor are they designed to accept code plug-ins that > represent the policies of an AS. One major exception is people adding > advertising and surveillance blockers like EFF Privacy Badger to their > browser. > > > > The user experience implications of having SSI data model standards and > GNAP protocol standards is that today's password managers (I have 250 RS > relationships in mine) will evolve to also control an AS agent. Just like= I > might register a W3C DID with an RS instead of an email address, my polic= y > manager might display to me the token policies that will be applied by my > AS to the personal data I can control at that RS. > > > > In some cases, my AS will allow me to modify those policies just like the > obnoxious cookie policy settings do today. The BIG difference with GNAP i= s > that I choose my AS separately from the RS so the dark patterns associate= d > with today's cookie policies experience are no longer possible. GNAP mean= s > the RS exposes an API rather than a UI. > > > > I've gone on far too long to address the issue of the AS as an identity > provider. It's fair to think of it that way. As it turns out, in the SSI > Secure Data Storage WG, we are debating the difference between an Encrypt= ed > Data Vault and an Identity Hub. As far as I'm concerned, the Identity Hub > is mostly a GNAP AS. Join us on Thursdays at 4 PM ET > https://lists.identity.foundation/g/sds-wg/wiki/Home > > > > Adrian > > > > > > > > On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > > > > > Am 19.02.2021 um 23:50 schrieb Adrian Gropper : > > =EF=BB=BF > > I agree with the first two of Justin's responses but not the last one. > > > > It's confusing to think that there are more RS than AS. > > > > the OAuth deployments I=E2=80=98m aware of typically have much more RSs t= han ASs. > Why? Because AS and a set of RSs belong to the same security domain (e.g.= a > certain business) and it=E2=80=99s the AS=E2=80=99s responsibility to ens= ure secure and > convenient access to the APIs provided by this RSs. For example: there is= a > AS controlling access to a cloud, streaming, and messaging services of th= e > same business. In case of open banking, the bank=E2=80=98s AS is (on beha= lf of the > user) authorizing access to APIs for account information as well as payme= nt > initiation and potentially other services. > > > > Technically, the respective AS and RSs set up a trust relationship and > agreed on ways to share authorization and user data in order enable secur= e > API access. > > > > I read your ideas regarding self-sovereign ASs with great interest and go= t > some observations/questions: > > - A personal AS could certainly control access to a person=E2=80=98s reso= urces. I > assume the person=E2=80=98s RSs would only accept access tokens signed by= the RO. > Am I right? > > - Do you envision this AS to be able to control access to any kind of RS? > How is the AS supposed to know what authorization data this RS needs in > order to perform access control decisions? What data will be exchanged? > > - How would this person delegate access to her resources to someone else? > > - Are you aware of deployments implementing this philosophy? > > - What are the implications in terms of user experience? > > > > In my experience coupling between AS and RS is very tight. I have a hard > time to see how self-sovereign ASs would work. It feels like such an AS i= n > the end is an identity provider of some sort, which brings me to what > Justin proposed. I would assume using SSI credentials to authenticate > towards ASs is feasible and might have value but I=E2=80=98m skeptical ab= out the AS > part. > > > > best regards, > > Torsten. > > > > From a human-centered (and hopefully IETF) perspective, each person might > control or specify a different AS for each of their personas or for each > child or incompetent delegate of them as guardian. We're familiar with > separate gmail addresses for each persona. > > > > ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial > bitcoin wallet), or brokers (as in data brokers and surveillance > capitalism). Any RS that is willing to have a recurring relationship with= a > persona could accept a GNAP AS endpoint instead of an email address. This > is easiest using HTTP, but GNAP need not exclude other RS / AS APIs and > transports. Designing around the uncensored specification of one's AS as = a > human right would greatly simplify many aspects of GNAP adoption. > > > > That said, GNAP should not ignore the RS business or > jurisdictional reasons to limit the authority of the AS. UMA 2.0 spent > years dancing around this issue with ideas like "cascading" AS and variou= s > centralized or federated AS concepts. My conclusion is that any RS can > always do whatever it wants and there's not much the authorization protoc= ol > can help with other than specifying a notification endpoint so that an RS > can warn (and seek confirmation) or log various exceptions. This turns ou= t > to be, after a year of testimony, the regulation that applies to HIPAA RS > APIs in the US. For this reason GNAP might include a notification protoco= l > in the AS specification, or not. > > > > I propose that embracing a self-sovereign agent is key to harmonizing the > SSI and GNAP standards. > > > > Adrian > > > > On Fri, Feb 19, 2021 at 2:30 PM Justin Richer wrote: > > Tobias, thanks for the great observations. Some reactions inline below. > > > > On Feb 18, 2021, at 7:59 PM, Tobias Looker > wrote: > > > > Justin, > > I think this is a great and timely conversation to be having given the > current interest around SSI and efforts like SIOP, I have been doing quit= e > a bit of work in this space as of recent, so thought I'd add a few of the > observations that I've made. > > In my opinion SIOP was really a bucket for solving quite a few different > problems, not just one. In particular I think its intent was to solve 3 > major ones: > > 1. Enabling portable identities > 2. Solving the NASCAR problem > 3. Exploring different deployment models for the provider > > To drill down briefly on these, note much of my terminology is OpenID > based due to SIOPs origin > > *Enabling portable identities *- In general today in the case of OpenID, > the end-users identity as understood by a relying party is scoped within > the domain of the provider. Which means if that provider goes out of > business or for whatever reason decides to no longer offer the same > identity services to the End-User, their identity is essentially gone. > Whilst there has been some interesting related work from groups like MODR= NA > on solutions to combat this like 'Account Porting', they often assume the > old provider remains online and willing to facilitate in the account > porting process so that the End-User can migrate to a new provider. SIOP > actually elected to do something different here by using cryptography, > instead of the End-User identifier being something like a GUID asserted > within the domain of the provider, SIOP defined this instead as a public > key fingerprint associated to a private key that's assumed to be under th= e > control of the user. In doing so the identity itself becomes portable > between providers by transferring the associated private key. Now this > approach does have drawbacks and arguably encourages what many would refe= r > to as bad cryptographic practise by not allowing any way to do key > rotation, however the idea was there. > > > > *How GNAP can solve for this?* By having flexibility around how the > resource owner / End-User is referred to by the Authorization server (e.g > allow the identifier to be something like a public key or a resolvable > identifier to public keys such as a DID) > > > > I personally think that GNAP should be a flexible :carrier: of identifier= s > and other bits of identity information. This is the main reason we went > with the Subject Identifiers draft from SECEVENT: it=E2=80=99s set up to = talk about > a variety of different kinds of identifiers, all of them asserted in the > context of the AS. If there=E2=80=99s a definition for a DID URL or a JWK= in the > sub_ids object structure, GNAP would be able to just use it directly > alongside every other format. I haven=E2=80=99t seen those proposed yet, = but it > would be easy to do and, in my mind, would be a better solution than the > portable identifiers proposal that was recently brought up in the FAPI > working group in OIDF. (A side note, but the main problem I have here is > that it=E2=80=99s pasting semantics and formats onto a field where none e= xisted > before, and that=E2=80=99s rife for problems. Better to have a structure = that takes > that into account from the start, in my view.) > > > > > *Solving the NASCAR problem *- One of those enduring problems in identity > systems, which I think is really about the three way negotiation going on > between the RP, the End-User and the Provider. SIOP's solution pushed for > most of the power in this decision making process to lie with the End-Use= r, > letting them decide who they want as their provider rather than RP's > providing an enumeration of who they support via provider icons on their > login page and End-Users having to select from those options. It > accomplished this via using a custom URL scheme of `openid://` where the > End-User would register their chosen provider as a protocol handler for t= he > `openid://` scheme. However, again as a solution it's not without it's > challenges, notably; only a single registration at a time can be supporte= d, > the actual identity of the provider remains blind to the RP until after t= he > request is sent and it requires registration or some form of default > handling (e.g when there is no provider registered). > > *How GNAP can solve for this?* I actually don't think this is core to > GNAP, there may be some considerations around discovery that are worth > paying attention to but not much in the core protocol design. > > > > SIOP doesn=E2=80=99t really solve the NASCAR issue since SIOP, by design,= becomes > yet one more login option among many. I think GNAP can help this by > enabling user-directed provider discovery to kick off the process, but I > agree that the core protocol doesn=E2=80=99t really have much to say here= , and > shouldn=E2=80=99t. > > > > *Exploring different deployment models for the provider* - This is the > most frequently talked about aspect of SIOP and perhaps the most > interesting to GNAP. I like to think about the scope of this issue as > designing to allow for either a partially or fully > distributed/decentralized provider, rather than a centralized one (e.g an > HTTP based AuthZ server). As you noted this does come with its challenges > many of which are technical in nature, i.e how to appropriately address a > decentralized provider and what protocols are used to communicate with th= e > provider. > > *How GNAP can solve for this?* I think that's what much of the discussion > on this thread will be about and whether there is a hybrid model where so= me > responsibility is still centrally administered like token issuance, while > allowing other aspects to occur in a more distributed manner. Ideally > though I'd like to see consideration for a completely distributed model t= oo. > > > > I agree that this seems to be the most interesting place for overlap. I > don=E2=80=99t actually think the =E2=80=9Chybrid=E2=80=9D approach centra= lizes things. Instead, you > can think of the RS as having an associated AS, and that AS accepting use= r > consent and claims at runtime from a variety of sources (wallets, VCs, > etc.). In this way, we aren=E2=80=99t talking about a single AS in the wo= rld > handling all of these requests, we=E2=80=99re talking about a distributed= network > of AS=E2=80=99s associated with an even more widely distributed set of RS= =E2=80=99s. SSI > and its associated technologies would help these =E2=80=9Clocal=E2=80=9D = AS=E2=80=99s issue access > tokens without the RO needing to have an account, or even necessarily > directly interacting with the AS. There=E2=80=99s currently a technology = gap there, > but my thoughts are that this is where the changes to the interaction mod= es > section can really come to play. > > > > I think the notion of a non-HTTP AS is interesting, but I=E2=80=99m not s= ure if > that=E2=80=99s something GNAP ought to be solving for. I think that there= =E2=80=99s a deep > value in building on top of HTTP for the core protocol, and not abstracti= ng > away concepts from it. Otherwise, you end up re-inventing layers, and you > get something like SOAP all over again. :) > > > > =E2=80=94 Justin > > > > > > Thanks, > > [image: Mattr website] > > > > > *Tobias Looker* > > Mattr > > +64 (0) 27 378 0461 > tobias.looker@mattr.global > > [image: Mattr website] > > > [image: Mattr on LinkedIn] > > > [image: Mattr on Twitter] > > > [image: Mattr on Github] > > > > This communication, including any attachments, is confidential. If you ar= e > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > > > > > On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault > wrote: > > Hi Justin, > > > > I agree that defining AS role primarily as a token issuer is a fruitful > idea. Solving this problem well would also respond to the challenges > discussed previously on the list. > > > > Cheers > > Fabien > > > > Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer = a =C3=A9crit : > > The last interim call had a lot of discussion on SSI technologies such as > digital wallets, and how those fit with GNAP. I think it=E2=80=99s worth = continuing > that conversation here on the list. There are a few issues in the tracker > that give some background, too: > > > > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 > > > > > There=E2=80=99s been a lot of interesting work recently in the OpenID Fou= ndation > around using the Self-issued OP (SIOP) functionality to bootstrap an SSI > style login. This makes extensive use of the implicit flow and front > channel messaging, but minimization of the front channel for message > passing is a key design tenet of GNAP (so much so that it=E2=80=99s inclu= ded in our > charter). Instead, GNAP has been built around an idea that everything > starts the same way: with an HTTP request to the AS. > > > > The idea of an on-device AS has been brought up a lot, and we need to > consider if and how we want to deal with these kinds of use cases. The mo= st > obvious way to address these would be to do some kind of clever off-HTTP > hack like SIOP, but keep in mind that even SIOP generally starts off with > an HTTP-based discovery call by the RP to make things work. > > > > My personal stance is that to do this, we need to re-evaluate our > assumptions about exactly what an AS does and what it needs to do those > things. In OAuth 2, it=E2=80=99s assumed that the AS is the device that= =E2=80=99s > authenticating the user, collecting consent, managing the client=E2=80=99= s > registration, and creating an access token based on whatever set of right= s > that are associated with all of those things. In UMA, this is turned arou= nd > a bit by letting the RO present a bunch of nebulous =E2=80=9Cclaims=E2=80= =9D interactively, > but still at the AS. > > > > With both of these, a key aspect remains: the AS needs to gather necessar= y > information, and issue the access token (or identifiers/assertions). > Because of how the protocol works, the client software now has a better > opportunity to present information to the AS, either directly in the > request or by introducing the AS to another software component during the > =E2=80=9Cinteraction=E2=80=9D phase. So, what if we think of the AS prima= rily as a =E2=80=9Ctoken > issuer=E2=80=9D? > > > > For example, if the client can present a verifiable credential (VC) that > represents the end user, the AS can validate that VC and make an access > token on behalf of that user, without having the user log in or interact > with the AS at all. This VC can contain whatever access rights the token > needs to represent, and the AS can translate that into an artifact that t= he > downstream RS=E2=80=99s can interpret, without having to see the original= VC or the > user at all. The AS is still HTTP based, but all the essential security a= nd > rights elements are provided by the wallet. In this way, we can expand on > the privacy-preserving aspects of OAuth and bridge the worlds of SSI and > web APIs without violating the basic nature of either. > > > > Coming from the OAuth world, it feels weird to issue tokens like this, bu= t > there=E2=80=99s precedent for this kind of thing. Today, a there are a nu= mber of > service-based OAuth AS's that are told what claims need to get put into t= he > access token by some trusted component. All of this happens outside the > OAuth protocol. In GNAP, I think it makes sense to account for this kind = of > thing in how we define the protocol. That isn=E2=80=99t to say all of the= se pieces > need to be defined in the core, but the base protocol ought to be able to > handle being extended in this direction as needed. > > > > I=E2=80=99m really interested to hear other people=E2=80=99s thoughts on = how this could > come together. > > > > =E2=80=94 Justin > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > > This communication, including any attachments, is confidential. If you ar= e not the intended recipient, you should not read it - please contact me im= mediately, destroy it, and do not copy or use any part of this communicatio= n or disclose anything about it. Thank you. Please note that this communica= tion does not designate an information system for the purposes of the Elect= ronic Transactions Act 2002. > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > > https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txau= th&source=3Dgmail-imap&ust=3D1614379828000000&usg=3DAOvVaw3avsUGQ48fo1OUQV0= vyyKd > > > > > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --0000000000001587f005bc1fa6e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Francis,

    I deeply want to understand= what use-cases GNAP may be missing but I'm having trouble understandin= g your requirement and don't have the benefit of banking world experien= ce. It doesn't=C2=A0matter to me whether GNAP is missing a use-case rel= ated to SSI or not. I just want to understand any limitations=C2=A0we might= be building=C2=A0into GNAP 1.0

    I hope some of thi= s helps us come to a common vocabulary...

    1. I thi= nk in terms of delegation. The GNAP AS is a delegate of the RO. The RO (or = RQ) uses a user agent to interact with the AS. This user-agent could be a w= eb browser or a mobile app. I assume that users can choose user agents that= include a HSM such as a FIDO2 or SIM card and I hope that's encouraged= but if an AS wants to deal with username / password, I would not prohibit = that.

    2. The RS is another kind of delegation. As = with the AS, the RO can approach the RS directly with a user agent and exer= cise their privilege of specifying an AS as their delegate if the RS offers= that feature. If the RS does not offer that feature to the RO, then I don&= #39;t think GNAP is very relevant. If the RS restricts the RO's choice = of ASs to a list or federation then GNAP still applies but in this case SSI= principles are likely being trampled.=C2=A0

    3. Th= e RQ relationship with the RS is _not_ delegation. It is authorization. Thi= s is true whether the RQ happens to be the RO or a separate party. I consid= er the RQ - RS relationship to be mediated by a=C2=A0Client, not a user age= nt. In some cases, the RQ user agent is also their client but I hope that G= NAP=C2=A0never makes this assumption. In other words, the party that intera= cts with the AS may not be the same as the party that interacts with the RS= because we want to encourage the ability for the RQ to delegate to another= end user and the client of that end user. This is critical to effective wo= rkflows in the real world.

    4. This raises issues a= round the responsibility of the RS to honor their commitment as a delegate = of the RO while also supporting legitimate privacy interests of the RQ or t= he delegate of the RQ as well as jurisdictional mandates that could force t= he RS to disregard a valid authorization token ("export restriction&qu= ot;) or accept an authorization token that was not rooted in trust of the A= S ("break the glass").

    To summarize, GNA= P _should_ deal with delegation as distinct from authorization. Some aspect= s of delegation _may_ be out of band for GNAP because GNAP is an authorizat= ion protocol. The case of an authorization token being part of a delegation= chain _should not_ be precluded by GNAP.=C2=A0

    Th= e transport and API between a user agent and an AS and a user agent and an = RS are not a matter of authorization and, although critically important, mi= ght not need to be specified by GNAP.

    I've not= used any SSI terminology above. Can you help me understand what SSI, banki= ng, or other use-cases I may be missing?

    - Adrian<= /div>

    On Wed, Feb 24, 2021 at 8:15 PM Francis Pouatcha <fpo@adorsys.de> wrote:

    Justin, Adrian,=C2=A0

    =C2=A0

    in my initial contributions, I did refer to SSI just as a sample use case=C2=A0user device generated=C2=A0token. We h= ave a lot of example out there running with Fido, EMV, electronic id cards, passports.

    =C2=A0

    Focus on the SSI philosophy might distract from the main issue: having=C2=A0user device generated cryptograms.

    =C2=A0

    Nevertheless, SSI is a good framework to present the use case.

    =C2=A0

    Let distinguish between:

    - a verifiable credential (VC) and

    - a verifiable presentation (VP).

    =C2=A0

    A VC might be produced by an authority (let assume an AS) in a direct negot= iation between RO and AS. No involvement of the Client.=C2=A0 I will call t= his a direct interaction.

    =C2=A0

    The VP is produced by the RO and presented to the Client. No involvement of= the AS. This is also a direct interaction.

    =C2=A0

    The presentation of this original RO produced VP by a Client to an RS might= require a new presentation produced by the Client and warping the =C2=A0or= iginal VP. I call this an=C2=A0embedded interaction. I = am missing this one in GNAP.

    =C2=A0

    The =E2=80=98Embedded=E2=80=99 suggestion did not make it pass the i= nitial discussion, because we were unable to justify it legitime use to the= OAuth legacy folks. We have been using this interaction mode in the bankin= g world for the last 20 years through diverse protocols.

    =C2=A0

    By adopting the embedded interaction, GNAP bridges the way to SSI.

    =C2=A0

    Please to not talk about =E2=80=9Cembedding user password=E2=80=9D a= la =E2=80=9Cpassword grant=E2=80=9D. I am referring to allowing a c= lient carry a cryptogram produced by the RO to the RS.

    =C2=A0

    If we define the producer of the Token to be an AS, the we will have to sho= w a mortal how to run the http based A-(Server) on the user device.<= u>

    =C2=A0

    Even if we narrow the definition of the AS to producing the VC and not the = VP, we still have a problem, as some VC might be produced by the user.

    =C2=A0

    In the EU we will be witnessing eIDAS certificates issued to user, allowing= them to produce their own VC, without the help of server based AS? Shall t= his make those VC producing applications running on the user device AS? The= n we will have to redefine AS.

    =C2=A0

    /Francis

    =C2=A0



    Fro= m: Francis Pouatcha <Francis.Pouatcha@adorsys.com>
    Sent: Thursday, February 25, 2021 1:13 AM
    To: Justin Richer <jricher@mit.edu>; Adrian Gropper <agropper@healthurl.com>
    Cc: Francis Pouatcha <fpo@adorsys.de>; Denis <denis.ietf@free.fr>; txauth gnap <txauth@ietf.org>
    Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI
    =C2=A0

    Justin, Adrian,

    =C2=A0

    in my initial contributions, I did refer to SSI just as a sample use case <= b>user device generated token. We have a lot of example out there runni= ng with Fido, EMV, electronic id cards, passports.

    =C2=A0

    Focus on the SSI philosophy might distract from the main issue: having u= ser device generated cryptograms.

    =C2=A0

    Nevertheless, SSI is a good framework to present the use case.

    =C2=A0

    Let distinguish between:

    - a verifiable credential (VC) and

    - a verifiable presentation (VP).

    =C2=A0

    A VC might be produced by an authority (let assume an AS) in a direct negot= iation between RO and AS. No involvement of the Client.=C2=A0 I will call t= his a direct interaction.

    =C2=A0

    The VP is produced by the RO and presented to the Client. No involvement of= the AS. This is also a direct interaction.

    =C2=A0

    The presentation of this original RO produced VP by a Client to an RS might= require a new presentation produced by the Client and warping the =C2=A0or= iginal VP. I call this an embedded interaction. I am missing this one in GNAP.

    =C2=A0

    The =E2=80=98Embedded=E2=80=99 suggestion did not make it pass the i= nitial discussion, because we were unable to justify it legitime use to the= OAuth legacy folks. We have been using this interaction mode in the bankin= g world for the last 20 years through diverse protocols.

    =C2=A0

    By adopting the embedded interaction, GNAP bridges the way to SSI.

    =C2=A0

    Please to not talk about =E2=80=9Cembedding user password=E2=80=9D a= la =E2=80=9Cpassword grant=E2=80=9D. I am referring to allowing a c= lient carry a cryptogram produced by the RO to the RS.

    =C2=A0

    If we define the producer of the Token to be an AS, the we will have to sho= w a mortal how to run the http based A-(Server) on the user device.

    =C2=A0

    Even if we narrow the definition of the AS to producing the VC and not the = VP, we still have a problem, as some VC might be produced by the user.

    =C2=A0

    In the EU we will be witnessing eIDAS certificates issued to user, allowing= them to produce their own VC, without the help of server based AS? Shall t= his make those VC producing applications running on the user device AS? The= n we will have to redefine AS.

    =C2=A0

    /Francis

    =C2=A0

    =C2=A0

    From: Justin Richer <jricher@mit.edu>
    Date: Wednesday, February 24, 2021 at 1:58 PM
    To: Adrian Gropper <agropper@healthurl.com>
    Cc: Francis Pouatcha <fpo@adorsys.de>, Denis <denis.ietf@free.fr>, txauth gnap <txauth@ietf.org>
    Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI

    +1 to this. In my opinion, building on anything other than HTTP right now i= s speculation, at best. And building an abstraction from zero-to-one concre= te manifestations is a recipe for disaster. Once a second thing comes along= , you inevitably realize that you put the abstraction points in the wrong place and have in fact baked in a = lot of assumptions about your base case into what was supposed to be an abs= traction layer.=C2=A0

    =C2=A0

    Instead, if there=E2=80=99s a desire to build out GNAP on top of other prot= ocols, then it should be :translated: to those protocols. This happened wit= h OAuth being built on top of COAP in ACE, without OAuth defining an abstra= ction layer ahead of time. And I=E2=80=99ll wager that if we had defined such a layer, it would not have considered things l= ike the multi-tiered client structures that are in ACE, or the key distribu= tion challenges in the IoT environment. Abstractions can come after the fac= t to aid future translations, but translation is nearly always more practical.=C2=A0

    =C2=A0

    But my point in starting this thread is that I think we can set up appropri= ate extension points for novel elements without throwing out the entire bas= e protocol, or creating something overly abstract. So I think we can keep t= he =E2=80=9CAS=E2=80=9D component and the central HTTP-based protocol but have places where these other elements, like SSI w= allets, can come in. I think we need to get away from the false conclusion = that the SSI wallet has to :be: the AS. Instead, I think the SSI wallet can= feed information into an AS in order for the AS to do its job.

    =C2=A0

    =C2=A0=E2=80=94 Justin



    On Feb 24, 2021, at 12:47 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    =C2=A0

    It might help the GNAP scoping discussion relative to SSI if we consider tw= o separate domains:=C2=A0

    - Registration: The relationship between the RO and the RS prior to = any GNAP Client entering the picture, and

    - Authorization: The interaction protocols between the user agents o= f end users and servers

    =C2=A0

    Fact: Only two SSI standards (VC and DID) are established enough for us to = reference in GNAP and they are both merely data models, not protocols. Neit= her of these data models is particularly=C2=A0concerned with delegation pro= tocols although there is going to be some impact from things like multi-signature schemes and filtering of capa= bilities.

    =C2=A0

    IMHO, GNAP as a delegation protocol=C2=A0standard cannot presume the succes= s or applicability of any SSI inspired protocols, including DIDcomm or Conf= idential Storage, that are still trying to figure out their relationship to= HTTP.=C2=A0

    =C2=A0

    Also, IMHO, SSI is not synonymous with protocols that presume a Holder as a= mandated intermediary store for any attribute that moves between an issuer= and a verifier. There are many, maybe most, use cases where SSI would be b= etter served by control of the attribute over actual possession of the attribute.

    =C2=A0

    Adrian

    =C2=A0

    =C2=A0

    =C2=A0

    On Wed, Feb 24, 2021 at 12:09 PM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.o= rg> wrote:

    Integrating GNAP and SSI requires a lot of f= undamentals:

    =C2=A0

    • AS had their essence in the fact that human = held devices were not able to produce authorization sharable to client and = RS
    • If the human held device can do the work, it= is natural the momentum will shift in that direction. This is what is happ= ening with SSI.
    • Sharing all views of Adrian mention in this = thread(no need to repeat).=C2=A0
    • But repeating the keyword: ZTA. Keeping cust= odian, server centered architectures under control is getting tougher as ti= me goes by.

    In GNAP initial discussion, we walked throug= h a lot of abstract diagram, that could have allowed production of authoriz= ation and authentication material (token) by human held devices. The intent= ion was inspired from SSI discussions.=C2=A0

    =C2=A0

    IF

    =C2=A0 Justin is asking to reconsider an int= egration of SSI,

    =C2=A0

    THEN

    we need to review the abstract protocol flow= s:

    • roles
    • entities
    • relationships

    We will have to start by taking the http pro= tocol constraint out of the charter.

    =C2=A0

    BTW

    • I agree with Justin: "The RS decides on= how to consume a presented token."
    • I agree with Denis: "AS plays no role a= nd shall have no influence on the RS decision on how to consume a token.&qu= ot;

    =C2=A0

    THEN

    We must start by sharping the meaning of an = AS (in the context of GNAP). Discussion might lead to a retirement of this = term. As mortals might have a hard time considering a user held device a se= rver.

    =C2=A0

    END IF

    =C2=A0

    =C2=A0

    Nevertheless, the transition from (http)-AS = based token production to user device-based token production will need some= 10+ years to complete. Still a lot of challenges around how to protect key= s held on user devices against damage, loss of device, malware, ransomware, social engineered attack.

    =C2=A0

    Can GNAP be the main vehicle for this transi= tion? Maybe. Despite the (too) strong reliance on the OAuth legacy (even if= GNAP does not promise backward compatibility to OAuth), an embedded interaction that allows the client to carry the user device= produced token to the resource server might pave way for this transition. = I campaigned for consideration of an embedded interaction in the initial conversation. I am not sure this= was taken into account. Still must find time to review the current draft.<= /span>

    =C2=A0

    =C2=A0

    /Francis

    =C2=A0

    =C2=A0

    From: TXAuth <txauth-bounces@ietf.org> on behalf of Denis <denis.ietf@free.fr>=
    Sent: Tuesday, February 23, 2021 12:51 PM
    To: Justin Richer <jricher@mit.edu>; txauth gnap <txauth@ietf.org>
    Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI

    =C2=A0

    Hi=C2=A0 Justin,

    =C2=A0

    See my comments between the lines.

    An important aspect in the discussion here, that I agree with, is that the = RS needs to be able to decide which AS it talks to.

    =C2=A0While I would agree with such a sentence i= n the OAuth WG, I don't believe that this sentence is applicable in gen= eral in the context of GNAP.
    A RS does not need to "talk to" any AS. A RS decides which AS(s) = it trusts to issue access tokens that contains some set of privileges.

    But inherent in that is that it=E2=80=99s not the user=E2=80=99s decision, = or the AS=E2=80=99s decision, it=E2=80=99s the RS=E2=80=99s decision who it= will trust to get tokens from.

    A RS does not necessarily need to trust all the = access tokens issued by a given AS, but only access tokens from a given AS = that contain
    a given set of privileges.

    And no matter what our philosophy, at the end of the day the RS will always= have the choice of whether to trust an inbound request.

    Not exactly: the RS will apply the rules given b= y the RO.

    Which is why, to me, this really brings us to the question of what an AS pr= ovides. The AS gives the RS a token that the RS decides to trust,
    and that the RS can understand (either directly with something like JWT or = indirectly with something like introspection).
    But the AS also needs to decide what to put INTO that token. As a consequen= ce, the AS can get that information from any number of places.
    The information could be provided in a trusted way by the end user to the A= S =E2=80=94 but this does NOT necessarily mean that the AS belongs
    to the user or is under their control.=C2=A0

    =C2=A0

    Basically, I think we=E2=80=99re trying to hard to map the OAuth general-co= ncept of the RO having an account at the AS and logging in to it before aut= horizing the request.
    I think that the call for =E2=80=9Cevery user to have their own AS=E2=80=9D= is such a huge non-starter in so many domains that it hampers the solution= space if that=E2=80=99s what we presume.
    It=E2=80=99s up to the RS to decide who it trusts, not the end user and not= the RO.=C2=A0

    =C2=A0

    I think we should ALLOW it, and we can be clearer in GNAP that that=E2=80= =99s one possible model, but not the only one, and not even the general one= .
    The AS manages all of the information and interconnections needed to create= an access token that the RS will accept, and it is in charge of signaling = to the RS what that token=E2=80=99s good for.

    I disagree: the AS is NOT in charge of signaling= to the RS what that token=E2=80=99s good for. It is up to the RS to decide= which privileges it will accept
    among all the privileges included into an access token.

    However, if the AS can learn through some other means that a specific ident= ified user has consented and provided appropriate information in a trusted = way,
    then THAT information can be baked into the token by the AS. =E2=80=94 impo= rtantly, in a way that the RS=E2=80=99s the AS protects can understan= d.

    I disagree: Trust relationships are not bilatera= l but only unilateral. An AS does not need to have any specific prior relat= ionship with a given RS.
    It is up to the RS(s) to decide which AS(s) it trust(s) an= d for which privileges.

    This last bit is where general opacity of tokens is important= here. There=E2=80=99s a natural security boundary that arises from this mo= del. What I=E2=80=99m proposing here is just that we=E2=80=99re more explic= it about what can be put INTO that boundary. That=E2=80=99s where I=E2=80=99m seeing a lot of this innovation in the SSI space fitting. You= =E2=80=99re not coming up with some universal access token that the RS will= accept, but you=E2=80=99re able to provide universal claims and artifacts = that an AS can process and translate into a token the RS will accept and do the right thing with= .

    Your argumentation about token opacity is making= the assumption that the AS and the RS need to have a prior relationship be= fore any access can take place.
    While this was valid with OAuth, this is no more valid in the context of GN= AP.=C2=A0 The client should be able to inform the AS about the access token= format(s) acceptable to the RS.
    Then the client may indicate to the AS these acceptable formats. If the RS = and the AS have an access token format in common, then the process may cont= inue.

    When only attributes (i.e. not rights) are being= requested to an AS by the client, the client does not need to disclose the= identity of the RS to the AS,
    which has the major advantage to prevent the AS to act as Big Brother.

    =C2=A0=C2=A0=C2=A0 Note: this does not pr= eclude the use of rights, in particular in the context of a single organiza= tion or enterprise.

    Denis

    =C2=A0

    =C2=A0=E2=80=94 Justin



    On Feb 21, 2021, at 9:40 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    =C2=A0

    Hi Torsten,

    =C2=A0

    Thank you for raising all of these excellent points. I hope we can all answ= er them and maybe even add a section to the wiki. I'll start...

    =C2=A0

    You're right that OAuth deployments almost exclusively put the AS and R= S in the same domain. If OAuth were adequate to today's needs we probab= ly would not be here doing GNAP. Since OAuth, we have increasing privacy co= ncerns and security disasters. GDPR, for example, separates the role of a data controller from a data processor and= treats them as separate legal entities. To oversimplify GDPR, the data pro= cessor is spared privacy responsibility and cost.

    =C2=A0

    You are also right to mention open banking as a use-case. Open banking has = not adopted UMA 2.0 (on which I have worked for almost a decade) which is b= ased on OAuth. PSD2 and similar regulations do not tie the AS and RS to the= same security domain but they presume a narrow federation of licensed (and regulated) ASs as payment processors = for subjects to choose among. This centralization to regulated fiduciaries = is a privacy trade-off that makes sense in banking. The fiduciary can be bo= nded so they can refund the money to the subject in case of a security breach. This privacy-security tradeof= f does not make sense in healthcare and other domains where the consequence= s of a breach are not easily reversed.

    =C2=A0

    This thread is about aligning GNAP and SSI. SSI does not abide centralizati= on, censorship, or surveillance. If GNAP makes any assumptions that result = in either a tight coupling between AS and RS (surveillance) or even a feder= ated fiduciary (centralization) we will lose out on the benefits of progress in digital identity that is n= ow driving a lot of public-sector initiatives and starting to bleed over in= to private sector practices. Zero Trust Architecture is an example and OAut= h is not well suited for ZTA.

    =C2=A0

    As you said, "technically, the respective AS and RSs set up a trust re= lationship and agreed on ways to share authorization and user data in order= [to] enable secure API access." This is where GNAP operates and we ne= ed to avoid _any_ restrictions on either the AS or the RS being self-sovereign. Examples of a self-sovereign RS could b= e a personal data store or an encrypted data vault like the ones we work on= in W3C/DIF. Any AS can be self-sovereign if the subject controls all of th= e policies and these policies are not shared, in the same way a private key is never not shared.=C2=A0

    =C2=A0

    Continuing your quote:

    I read your ideas regarding self-sovereign ASs with great interest and got = some observations/questions:
    - A personal AS could certainly control access to a person=E2=80=98s resour= ces. I assume the person=E2=80=98s RSs would only accept access tokens sign= ed by the RO. Am I right?

    Yes, and. There is debate in various SSI WGs whether a RS such as an Encryp= ted Data Vault should respond to capabilities or tokens. Either way, the RO= is in control of the signature but a personal AS is a delegate of the RO (= either directly or via a mobile user agent). With capabilities=C2=A0such as ZCAP-LD or biscuits, the token= signature=C2=A0allows for filtered delegation.

    =C2=A0

    - Do you envision this AS to be able to control access to any kind of RS? H= ow is the AS supposed to know what authorization data this RS needs in orde= r to perform access control decisions? What data will be exchanged?

    Yes. The whole point, as far as I'm concerned, is to design human cente= red standards. This is how W3C and IETF are different. Other SDOs tend to b= e operated for institutional benefit. A person-centered AS must work across= institutional domains.=C2=A0

    =C2=A0

    This, as you point out, brings up the problem of scope. Ontologies and data= models are, justifiably, domain-specific. I, for example, work around the = HL7 data model standards and APIs like FHIR that are controlled by healthca= re business interests. It's unreasonable to expect a general solution to the data model problem, although folks of = the Linked Data persuasion might disagree.

    =C2=A0

    Every RS gets to decide what data models and ontologies it supports. These = decisions are public and sometimes standardized for the benefit of the clie= nts. A person's AS must read and maybe understand the RS data model in = order to issue tokens just like the client needs to do in order to make a request to the AS. In our HIE of One= Trustee project, we allow the self-sovereign subject to inherit AS policie= s from self-sovereign communities they choose and then modify the policies = if they want. In this way, communities compete for members on the basis of policy bundles the same way churches c= ompete for congregants.

    =C2=A0

    - How would this person delegate access to her resources to someone else?

    There are two "persons" to consider. The RO delegates to an RQ. B= ut the RQ, in real life, is part of a team and often delegates to associate= s. With or without capabilities, GNAP needs to deal with this reality that = RO and RQ user agents may be different from the client that actually presents a token to the=C2=A0RS. Some of this dif= ference between user agents and clients we may be able to keep out of band.=

    =C2=A0

    - Are you aware of deployments implementing this philosophy?

    Other than our HIE of One demonstration project in healthcare, no. We start= ed HIE of One before SSI in order to drive the transition from UMA to UMA 2= .0 and inform various healthcare regulatory=C2=A0priorities. We then jumped= on SSI immediately and added it to the UMA 2 AS we call Trustee. Now we are trying to align SSI and GNAP in order= to enable human-centered protocols and zero-trust architecture.=C2=A0

    =C2=A0

    - What are the implications in terms of user experience?

    Right now, the human-centered user experience assumes a secure element and = web browser as user agents on a mobile device. Neither of these is readily = accessible=C2=A0as a server nor are they designed to accept code plug-ins t= hat represent the policies of an AS. One major exception is people adding advertising and surveillance blockers= like EFF Privacy Badger to their browser.=C2=A0

    =C2=A0

    The user experience implications of having SSI data model standards and GNA= P protocol standards is that today's password managers (I have 250 RS r= elationships in mine) will evolve to also control an AS agent. Just like I = might register a W3C DID with an RS instead of an email address, my policy manager might display to me the tok= en policies that will be applied by my AS to the personal data I can contro= l at that RS.=C2=A0

    =C2=A0

    In some cases, my AS will allow me to modify those policies just like the o= bnoxious cookie policy settings do today. The BIG difference with GNAP is t= hat I choose my AS separately from the RS so the dark patterns associated w= ith today's cookie policies experience are no longer possible. GNAP means the RS exposes an API rather than a UI.=

    =C2=A0

    I've gone on far too long to address the issue of the AS as an identity= provider. It's fair to think of it that way. As it turns out, in the S= SI Secure Data Storage WG, we are debating the difference between an Encryp= ted Data Vault and an Identity Hub. As far as I'm concerned, the Identity Hub is mostly a GNAP AS. Join us on Thu= rsdays at 4 PM ET=C2=A0https://lists.identity.foundation/g/sds-wg/w= iki/Home=C2=A0

    =C2=A0

    Adrian

    =C2=A0

    =C2=A0

    =C2=A0

    On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt <torsten@lodderstedt.net> w= rote:

    =C2=A0



    Am 19.02.2021 um 23:50 schrieb Adrian Gropper <agropper@healthurl.com>:

    =EF=BB=BF

    I agree with the=C2=A0first=C2=A0two of Justin's responses but not the = last one.

    =C2=A0

    It's confusing to think that there are more RS than AS.

    =C2=A0

    the OAuth deployments I=E2=80=98m aware of typically have much more RSs tha= n ASs. Why? Because AS and a set of RSs belong to the same security domain = (e.g. a certain business) and it=E2=80=99s the AS=E2=80=99s responsibility = to ensure secure and convenient access to the APIs provided by this RSs. For example: there is a AS controlling access to a cloud, str= eaming, and messaging services of the same business. In case of open bankin= g, the bank=E2=80=98s AS is (on behalf of the user) authorizing access to A= PIs for account information as well as payment initiation and potentially other services.=C2=A0

    =C2=A0

    Technically, the respective AS and RSs set up a trust relationship and agre= ed on ways to share authorization and user data in order enable secure API = access.

    =C2=A0

    I read your ideas regarding self-sovereign ASs with great interest and got = some observations/questions:

    - A personal AS could certainly control access to a person=E2=80=98s resour= ces. I assume the person=E2=80=98s RSs would only accept access tokens sign= ed by the RO. Am I right?

    - Do you envision this AS to be able to control access to any kind of RS? H= ow is the AS supposed to know what authorization data this RS needs in orde= r to perform access control decisions? What data will be exchanged?

    - How would this person delegate access to her resources to someone else?

    - Are you aware of deployments implementing this philosophy?

    - What are the implications in terms of user experience?

    =C2=A0

    In my experience coupling between AS and RS is very tight. I have a hard ti= me to see how self-sovereign ASs would work. It feels like such an AS in th= e end is an identity provider of some sort, which brings me to what Justin = proposed. I would assume using SSI credentials to authenticate towards ASs is feasible and might have value b= ut I=E2=80=98m skeptical about the AS part.

    =C2=A0

    best regards,

    Torsten.



    >From a human-centered (and hopefully IETF) perspective, each person might c= ontrol or specify a different AS for each of their personas or for each chi= ld or incompetent delegate of them as guardian. We're familiar with sep= arate gmail addresses for each persona.

    =C2=A0

    ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial bitcoi= n wallet), or brokers (as in data brokers and surveillance capitalism). Any= RS that is willing to have a recurring relationship with a persona could a= ccept a GNAP AS endpoint instead of an email address. This is easiest using HTTP, but GNAP need not exclude= other RS / AS APIs and transports. Designing around the uncensored specifi= cation=C2=A0of one's AS as a human right would greatly simplify many as= pects of GNAP adoption.

    =C2=A0

    That said, GNAP should not ignore the RS business or jurisdictional=C2=A0re= asons to limit the authority of the AS. UMA 2.0 spent years dancing around = this issue with ideas like "cascading" AS and various centralized= or federated AS concepts. My conclusion is that any RS can always do whatever it wants and there's not much the author= ization protocol can help with other than specifying a notification endpoin= t so that an RS can warn (and seek confirmation) or log various exceptions.= This turns out to be, after a year of testimony, the regulation that applies to HIPAA RS APIs in the US. For = this reason GNAP might include a notification protocol in the AS specificat= ion, or not.

    =C2=A0

    I propose that embracing a self-sovereign agent is key to harmonizing the S= SI and GNAP standards.

    =C2=A0

    Adrian

    =C2=A0

    On Fri, Feb 19, 2021 at 2:30 PM Justin Richer <jricher@mit.edu> wrote:

    Tobias, thanks for the great observations. Some reactions inline below.



    On Feb 18, 2021, at 7:59 PM, Tobias Looker <tobias.looker@mattr.global> wrot= e:

    =C2=A0

    Justin,

    I think this is a great and timely conversation to be having given the curr= ent interest around SSI and efforts like SIOP, I have been doing quite a bi= t of work in this space as of recent, so thought I'd add a few of the o= bservations that I've made.

    In my opinion SIOP was really a bucket for solving quite a few different pr= oblems, not just one. In particular I think its intent was to solve 3 major= ones:

    1. Enabling portable identities
    2. Solving the NASCAR problem
    3. Exploring different deployment models for the provider

    To drill down briefly on these, note much of my terminology is OpenID based= due to SIOPs origin=C2=A0

    Enabling portable identities - In general today in the case of OpenI= D, the end-users identity as understood by a relying party is scoped within= the domain of the provider. Which means if that provider goes out of busin= ess or for whatever reason decides to no longer offer the same identity services to the End-User, their ident= ity is essentially gone. Whilst there has been some interesting related wor= k from groups like MODRNA on solutions to combat this like 'Account Por= ting', they often assume the old provider remains online and willing to facilitate in the account porting process so= that the End-User can migrate to a new provider. SIOP actually elected to = do something different here by using cryptography, instead of the End-User = identifier being something like a GUID asserted within the domain of the provider, SIOP defined this inste= ad as a public key fingerprint associated to a private key that's assum= ed to be under the control of the user. In doing so the identity itself bec= omes portable between providers by transferring the associated private key. Now this approach does have drawbacks and argu= ably encourages what many would refer to as bad cryptographic practise by n= ot allowing any way to do key rotation, however the idea was there.=C2=A0

    =C2=A0

    How GNAP can solve for this? By having flexibility around how the re= source owner / End-User is referred to by the Authorization server (e.g all= ow the identifier to be something like a public key or a resolvable identif= ier to public keys such as a DID)

    =C2=A0

    I personally think that GNAP should be a flexible :carrier: of identifiers = and other bits of identity information. This is the main reason we went wit= h the Subject Identifiers draft from SECEVENT: it=E2=80=99s set up to talk = about a variety of different kinds of identifiers, all of them asserted in the context of the AS. If there=E2=80=99s a defini= tion for a DID URL or a JWK in the sub_ids object structure, GNAP would be = able to just use it directly alongside every other format. I haven=E2=80=99= t seen those proposed yet, but it would be easy to do and, in my mind, would be a better solution than the portable identi= fiers proposal that was recently brought up in the FAPI working group in OI= DF. (A side note, but the main problem I have here is that it=E2=80=99s pas= ting semantics and formats onto a field where none existed before, and that=E2=80=99s rife for problems. Better to= have a structure that takes that into account from the start, in my view.)=




    Solving the NASCAR problem - One of those enduring problems in ident= ity systems, which I think is really about the three way negotiation going = on between the RP, the End-User and the Provider. SIOP's solution pushe= d for most of the power in this decision making process to lie with the End-User, letting them decide who they want= as their provider rather than RP's providing an enumeration of who the= y support via provider icons on their login page and End-Users having to se= lect from those options. It accomplished this via using a custom URL scheme of `openid://` where the End-User would= register their chosen provider as a protocol handler for the `openid://` s= cheme. However, again as a solution it's not without it's challenge= s, notably; only a single registration at a time can be supported, the actual identity of the provider remains blind= to the RP until after the request is sent and it requires registration or = some form of default handling (e.g when there is no provider registered).
    How GNAP can solve for this? I actually don't think this is core= to GNAP, there may be some considerations around discovery that are worth = paying attention to but not much in the core protocol design.

    =C2=A0

    SIOP doesn=E2=80=99t really solve the NASCAR issue since SIOP, by design, b= ecomes yet one more login option among many. I think GNAP can help this by = enabling user-directed provider discovery to kick off the process, but I ag= ree that the core protocol doesn=E2=80=99t really have much to say here, and shouldn=E2=80=99t.



    Exploring different deployment models for the provider - This is the= most frequently talked about aspect of SIOP and perhaps the most interesti= ng to GNAP. I like to think about the scope of this issue as designing to a= llow for either a partially or fully distributed/decentralized provider, rather than a centralized one (e.g an = HTTP=C2=A0based AuthZ server). As you noted this does come with its challen= ges many of which are technical in nature, i.e how to appropriately address= a decentralized provider and what protocols are used to communicate with the provider.

    How GNAP can solve for this? I think that's=C2=A0what much of th= e discussion on this thread will be about and whether there is a hybrid mod= el where some responsibility is still centrally administered like token iss= uance, while allowing other aspects to occur in a more distributed manner. Ideally though I'd like to see considera= tion for a completely distributed model too.

    =C2=A0

    I agree that this seems to be the most interesting place for overlap. I don= =E2=80=99t actually think the =E2=80=9Chybrid=E2=80=9D approach centralizes= things. Instead, you can think of the RS as having an associated AS, and t= hat AS accepting user consent and claims at runtime from a variety of sources (wallets, VCs, etc.). In this way, we aren=E2=80=99t = talking about a single AS in the world handling all of these requests, we= =E2=80=99re talking about a distributed network of AS=E2=80=99s associated = with an even more widely distributed set of RS=E2=80=99s. SSI and its associated technologies would help these =E2=80=9Clocal=E2=80=9D AS=E2= =80=99s issue access tokens without the RO needing to have an account, or e= ven necessarily directly interacting with the AS. There=E2=80=99s currently= a technology gap there, but my thoughts are that this is where the changes to the interaction modes section can really come to play.=C2= =A0

    =C2=A0

    I think the notion of a non-HTTP AS is interesting, but I=E2=80=99m not sur= e if that=E2=80=99s something GNAP ought to be solving for. I think that th= ere=E2=80=99s a deep value in building on top of HTTP for the core protocol= , and not abstracting away concepts from it. Otherwise, you end up re-inventing layers, and you get something like SOAP all over a= gain. :)

    =C2=A0

    =C2=A0=E2=80=94 Justin



    =C2=A0

    Thanks,

    3D"Mattr

    =C2=A0

    Tobias= Looker

    Mattr

    +64 (0) 27 378 0461
    tobias.look= er@mattr.global

    3D"Mattr

    3D"Mattr

    3D"Mattr

    3D"Mattr


    This communication, including any at= tachments, is confidential. If you are not the intended recipient, you shou= ld not read it - please contact me immediately, destroy it, and do not copy= or use any part of this communication or disclose anything about it. Thank you. Please note that this communicat= ion does not designate an information system for the purposes of the Electr= onic Transactions Act 2002.

    =C2=A0

    =C2=A0

    On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault <fabien.imbault@gmail.com> wrot= e:

    Hi Justin,

    =C2=A0

    I agree that defining AS role primarily as a token issuer is a fruitful ide= a. Solving this problem well would also respond to the challenges discussed= previously on the list.=C2=A0

    =C2=A0

    Cheers

    Fabien=C2=A0

    =C2=A0

    Le mer. 17 f=C3=A9vr. 2021 =C3=A0 23:27, Justin Richer <jricher@mit.edu> a =C3=A9crit= =C2=A0:

    The last interim call had a lot of discussion on SSI technologies such as d= igital wallets, and how those fit with GNAP. I think it=E2=80=99s worth con= tinuing that conversation here on the list. There are a few issues in the t= racker that give some background, too:

    =C2=A0

    =C2=A0

    There=E2=80=99s been a lot of interesting work recently in the OpenID Found= ation around using the Self-issued OP (SIOP) functionality to bootstrap an = SSI style login. This makes extensive use of the implicit flow and front ch= annel messaging, but minimization of the front channel for message passing is a key design tenet of GNAP (so much s= o that it=E2=80=99s included in our charter). Instead, GNAP has been built = around an idea that everything starts the same way: with an HTTP request to= the AS.=C2=A0

    =C2=A0

    The idea of an on-device AS has been brought up a lot, and we need to consi= der if and how we want to deal with these kinds of use cases. The most obvi= ous way to address these would be to do some kind of clever off-HTTP hack l= ike SIOP, but keep in mind that even SIOP generally starts off with an HTTP-based discovery call by the RP= to make things work.

    =C2=A0

    My personal stance is that to do this, we need to re-evaluate our assumptio= ns about exactly what an AS does and what it needs to do those things. In O= Auth 2, it=E2=80=99s assumed that the AS is the device that=E2=80=99s authe= nticating the user, collecting consent, managing the client=E2=80=99s registration, and creating an access token based on w= hatever set of rights that are associated with all of those things. In UMA,= this is turned around a bit by letting the RO present a bunch of nebulous = =E2=80=9Cclaims=E2=80=9D interactively, but still at the AS.=C2=A0

    =C2=A0

    With both of these, a key aspect remains: the AS needs to gather necessary = information, and issue the access token (or identifiers/assertions). Becaus= e of how the protocol works, the client software now has a better opportuni= ty to present information to the AS, either directly in the request or by introducing the AS to another sof= tware component during the =E2=80=9Cinteraction=E2=80=9D phase. So, what if= we think of the AS primarily as a =E2=80=9Ctoken issuer=E2=80=9D?=C2=A0

    =C2=A0

    For example, if the client can present a verifiable credential (VC) that re= presents the end user, the AS can validate that VC and make an access token= on behalf of that user, without having the user log in or interact with th= e AS at all. This VC can contain whatever access rights the token needs to represent, and the AS can transl= ate that into an artifact that the downstream RS=E2=80=99s can interpret, w= ithout having to see the original VC or the user at all. The AS is still HT= TP based, but all the essential security and rights elements are provided by the wallet. In this way, we can expand= on the privacy-preserving aspects of OAuth and bridge the worlds of SSI an= d web APIs without violating the basic nature of either.

    =C2=A0

    Coming from the OAuth world, it feels weird to issue tokens like this, but = there=E2=80=99s precedent for this kind of thing. Today, a there are a numb= er of service-based OAuth AS's that are told what claims need to get pu= t into the access token by some trusted component. All of this happens outside the OAuth protocol. In GNAP, I think it makes = sense to account for this kind of thing in how we define the protocol. That= isn=E2=80=99t to say all of these pieces need to be defined in the core, b= ut the base protocol ought to be able to handle being extended in this direction as needed.

    =C2=A0

    I=E2=80=99m really interested to hear other people=E2=80=99s thoughts on ho= w this could come together.

    =C2=A0

    =C2=A0=E2=80=94 Justin

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/= listinfo/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/= listinfo/txauth



    This communication, including any attachments, is confidential. If you a=
re not the intended recipient, you should not read it - please contact me i=
mmediately, destroy it, and do not copy or use any part of this communicati=
on or disclose anything about it. Thank you. Please note that this communic=
ation does not designate an information system for the purposes of the Elec=
tronic Transactions Act 2002.

    =C2=A0

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/= listinfo/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.google.com/url?q= =3Dhttps://www.ietf.org/mailman/listinfo/txauth&source=3Dgmail-imap&= ;ust=3D1614379828000000&usg=3DAOvVaw3avsUGQ48fo1OUQV0vyyKd

    =C2=A0



    =C2=A0

    --
    TXAuth mailing list
    TXAuth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth

    =C2=A0

    --0000000000001587f005bc1fa6e1-- From nobody Wed Feb 24 21:33:03 2021 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 E82843A12D0 for ; Wed, 24 Feb 2021 21:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=adorsys.de 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 5IPx-e-sQdAS for ; Wed, 24 Feb 2021 21:32:55 -0800 (PST) Received: from DEU01-FR2-obe.outbound.protection.outlook.com (mail-fr2deu01on2116.outbound.protection.outlook.com [40.107.135.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2D13A12CF for ; Wed, 24 Feb 2021 21:32:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cRDgHSZIXGYXkZ3g1kWwgEkQK6dHd6+3TstQNA5GJFnEYlY5NltHnoN60maVHMtcloPLkYGKnexLcMiVu0HYagNeiAa6jbw8WYjiZbFrZ9jQ3LdWyj8uSApkCaLU52C4j2HiiqbOM8rkpJX0PJbfsDFxSgivCS6eLKH/W17tlaQam8iGELElKS65Cgu16i88YDGtlsuD4zf3kr1120JCQ+BiqKSE4ptSZDXMKGVf622Q/JHWcMk8m+9p7rdyII2Tk5v3j9EAQKvGN+dNtmdWz8KQlC6Lb+UiDWOFHkLKDfo/tC9KZAGbGDVqSGCwOcKRWdn4fgF2YwC3pSNxuC4Emw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IcrqjKU3jtQR4CV26MGll4mDLC/faCoJPTkorHzcg1U=; b=DkbF0YQ3a7y39uqT7690GNeYvbrBlPmFtmLBFDRNLcbJOpQQEJj1LDGt/6/36S5aPxgBXZ86qXvXyf2fh1iSuqnhAkqe95w1dntGfnt+LS+Q5xOtgDCvdzaIUOwJMepP6plQAdv6gw9U0Cd4tabPMDUhz+/nQyguBip37VfDe4o6I8qmdxpOFSD7Z4kxKNLblKc3l6FXkBjide49/vHH6zwydmqrAwGxpLXRYGZIp4SqSEelMs0v5Jeb/fORc7lPUhjdI+wo+tTrqvVTqQS0+QL5nIrGLwQ77Y2rp1wB8ZeMHfo2TitA3GvH4UQBx0NW7VoInzrJNDovZ0skOska7A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=adorsys.de; dmarc=pass action=none header.from=adorsys.de; dkim=pass header.d=adorsys.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IcrqjKU3jtQR4CV26MGll4mDLC/faCoJPTkorHzcg1U=; b=3uMcjkp4wGLdCouaWLY7M60/o0iJRy/GmuC5cESC3YtWm6LUOd/pMqdBkplvWkcxYuT7zNNfyOrOBLxG3v+JfR+edGgbGGxAjoP/zmd/gCeiov65s7XzH+pGVeL+laXtK9F2ihbqJwwzTExlMSVcD9oLynlVXq8y4mUHdO0vOq7gZzmdTQNwjQRO6rRXarCNyZN4rphqDfGwgx7KFAWCEJ5QP0OcrLRHDhI/dLuQc8owCi40DCATiiiTa5Ny0ct+q70aHfaKGHSfxTdtBxwirdmip/Gi6swo0zxuVXoHTQQZ6/Vg5H8Caf9I9X2sABHUrCx3rAoEUEma4NwjM3jMIw== Received: from FR2P281MB0138.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:10::8) by FR2P281MB0107.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:10::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.9; Thu, 25 Feb 2021 05:32:46 +0000 Received: from FR2P281MB0138.DEUP281.PROD.OUTLOOK.COM ([fe80::bc2b:fddf:d610:ee71]) by FR2P281MB0138.DEUP281.PROD.OUTLOOK.COM ([fe80::bc2b:fddf:d610:ee71%3]) with mapi id 15.20.3912.009; Thu, 25 Feb 2021 05:32:46 +0000 From: Francis Pouatcha To: Adrian Gropper , Francis Pouatcha CC: Justin Richer , Denis , txauth gnap Thread-Topic: [GNAP] Integrating a GNAP AS with wallets and SSI Thread-Index: AQHXBXwe7b9/rWIGR0yOF6btTivnUKpdknMAgAEXjYCAATZHgIAAN+AAgAJGUgCAAFWagIAB1VCAgAEwxwCAAcSN74AAIH+AgAATxICAAFhA4YAAEPcfgAAPa4CAAC3asA== Date: Thu, 25 Feb 2021 05:32:45 +0000 Message-ID: References: <4EAA60A4-4800-400F-A70A-F7B7F1A6CB0A@mit.edu> <73cd4e8b-c843-ab87-c640-eea763b6002a@free.fr> <34DD2820-06F8-4226-A987-DF6F1105B87D@mit.edu> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: healthurl.com; dkim=none (message not signed) header.d=none;healthurl.com; dmarc=none action=none header.from=adorsys.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [65.33.158.162] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 08a5c990-c4c7-4487-49e9-08d8d94ec815 x-ms-traffictypediagnostic: FR2P281MB0107: x-ms-exchange-minimumurldomainage: mattr.global#706 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3044; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Iq4JQjlsfmse9rLMSm4g1JoZSKyCY0SGsl7QlBrGOwBdEoZPx9kilYpA62JMALJ2X+dQfQIiBEByFTCXFDfYVJfDlgrsNMWfsVP3gYbkkA7KkVlN3Xww/T37sMagJDrkd+b2GzNoITSlmCtm23vJva3AkYPXNCb1Mf/qpnk7EJ0IskWV4qAdRc1rFon4RyZgcExGmHXB3w2uS9m+QKOQ0saihBHdELi1g8RGVRaJgYaZO9Te9fAc72iK0bhYaBKdAxV2lUIb1Zrm94Q7BiUskqslLiEFit7JUqiUbIG+Y7plQJLFY4RPZMSr8zt1vDe1LauMGi3bqGhz0L/ox58H6zwQjrgQETfXx4szAvKlOYjKC0RWHbVkc5I9wAWcdlW72xbp60cGW0uKoNYrEzDlburWchoTHK+l7Iqv5H3vXYXnmN5SRkZqFbAf5vzkTc0KyoTB1c+L+uctAQ3FldSRwcl0f2a+P4laAayLgnTH4/5M6k1T4pXt+svq6EX7K/kRa5qB+fP1oKnmxlcMHz4O3VMYF8JZC+lK4OrN3Ay3EmTEQBycQgf0g3UhDZ0hNvDnfJfYzzZB0Eru3cicbr7z19mgMrIcehC1BzNLFkeP5bCr3LTB9KkAqbW7bxUI/B/Uyvo9deumy18Qaq9x5Q3AnQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0138.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(39830400003)(376002)(136003)(366004)(346002)(66476007)(64756008)(316002)(33656002)(66556008)(66446008)(54906003)(8936002)(8676002)(110136005)(26005)(4326008)(30864003)(7696005)(71200400001)(19627405001)(91956017)(55016002)(9686003)(166002)(53546011)(76116006)(86362001)(84040400003)(6506007)(52536014)(478600001)(186003)(2906002)(5660300002)(83380400001)(966005)(66946007)(18074004)(66574015)(15866825006)(559001)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?OPWSphNsTNayP1/2cPeWE+MSfO0M04ewhcRqN57Kzvmb1bS7z6Dt1wA6?= =?Windows-1252?Q?2E7/yaXeDjUWi+HrbTl/xXF288cW0Fa90B9M8YZWoDs8QQdPFmPnH9rd?= =?Windows-1252?Q?I3v/fHkqqKsgGFut44S53zvOnIRQlreWNG2qdlmIhqchgBA0jwrPuZHX?= =?Windows-1252?Q?Rin4geSIDxsjBNMN/tz5sQ1TQBAV4nCg8+In5DNfReqHTl5mD4m1aiWJ?= =?Windows-1252?Q?cv3F0wXVWr1yOXqj2XqcS2nWbk53bleOMUJHkTwnO0GbN6n5hvNR5Eqa?= =?Windows-1252?Q?+pz24OeNyc5NMdj87Za/Pf1M4bJM/PRAByqQTGr1U7dK1ulodbCj0XVd?= =?Windows-1252?Q?CKI4Py0DhxSNAI3k47PdFkV43DAmZvkeq6oSAAp7TLw1tthTm+K0iYTe?= =?Windows-1252?Q?R7T0uCFCfzvMsDUETgCbgDroCndNzaunjVuXgdR7C/Gtw21SfvKoG873?= =?Windows-1252?Q?2mc68TI+1m3FK7mkL0y9N1kpa1MhnP9r3sNsQtswMMOx96dJWdlp1eeO?= =?Windows-1252?Q?tcAI/Mq6HPkLYY0DPPnE3wy6zS8UI6c/1akdRBF3OUAPXndJplSJQKqD?= =?Windows-1252?Q?1YvkwyA+LJjQgnaeWtGFUL/MYiJGbyzYD9Wx6z3xiBRxqmXhVXbEeCR+?= =?Windows-1252?Q?ukacPDuqcyozoOZf2yXIc3dEvabpfRfaN1yFDwv3uPMupYxJAkq4vZcX?= =?Windows-1252?Q?RmMKwlA2fBohZRunktzlm8oaeaniDgEAp4D7VGd09F7AyUsfvQt5jiDK?= =?Windows-1252?Q?UZchL998IZHOseGzAWIXF1/BEDVcB6bX0xwvkHqlk/YF/1BjmYjGQbTT?= =?Windows-1252?Q?KIe+fiNweIPVC7iroD1UELOtn/yxGeQo1BpBr554b1q/vD+dMC2C9TQC?= =?Windows-1252?Q?/VW8Nh/tWuwB+4wqRrwzUTjry2v+giYltSiVxMJrhVDGuPkdio46A/v7?= =?Windows-1252?Q?ovyl5ztoq1uETapQrqce0cs8qEUu62FIumJqfYzLbl5UOL2O4Vv02xIg?= =?Windows-1252?Q?33pEuigxKA+epAYJFdtZGEhlieIRobQhf9plO9j8XhsiCzNHi1t1BSh/?= =?Windows-1252?Q?5dhOrDNb6IewwVT17L70BM7CkSShMVR7l/0zRDiItFrSnKYz3vEwztbw?= =?Windows-1252?Q?RoUbUR1oM99eIwUzOwX84bqq2HLqqfgCaJ7onyntnOxhld6C0ArGHlxi?= =?Windows-1252?Q?Ser+tsLmC6kx82uE7w5EZ747wcob3Ss15d+jyYUT/ws5fHs5ISfxQhnF?= =?Windows-1252?Q?beeDc/qNIPn5AKDXCVo=3D?= Content-Type: multipart/alternative; boundary="_000_FR2P281MB01385E9064D7D5F70B09DEAA8D9E9FR2P281MB0138DEUP_" MIME-Version: 1.0 X-OriginatorOrg: adorsys.de X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0138.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 08a5c990-c4c7-4487-49e9-08d8d94ec815 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2021 05:32:45.8807 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5e2c5484-e522-479d-91ca-515d6e0ce228 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yqbie50KFET6KtwQEe52eijW5AtZb8aPWn5jVybkNrvmIZiKWVWt8kbWtPEqCTPq9dMturRVxwXJlTgp3eZoREyXZv6PYmiQeFFrHaMtvGM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB0107 Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 05:33:01 -0000 --_000_FR2P281MB01385E9064D7D5F70B09DEAA8D9E9FR2P281MB0138DEUP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Adrian, inline, I deeply want to understand what use-cases GNAP may be missing but I'm havi= ng trouble understanding your requirement and don't have the benefit of ban= king world experience. It doesn't matter to me whether GNAP is missing a us= e-case related to SSI or not. I just want to understand any limitations we = might be building into GNAP 1.0 I hope some of this helps us come to a common vocabulary... 1. I think in terms of delegation. The GNAP AS is a delegate of the RO. The= RO (or RQ) uses a user agent to interact with the AS. This user-agent coul= d be a web browser or a mobile app. I assume that users can choose user age= nts that include a HSM such as a FIDO2 or SIM card and I hope that's encour= aged but if an AS wants to deal with username / password, I would not prohi= bit that. This is correct. What is we have a RO/RQ that doesn't need delegation? Dele= gation is only necessary is RO/RQ does not have the capability needed to th= e work. If RO/RQ can generate the token, we do not need to delegate to the = AS. 2. The RS is another kind of delegation. Yes. RS are delegate in that they manage resources on behalf of RO. As with the AS, the RO can approach the RS directly with a user agent and e= xercise their privilege of specifying an AS as their delegate if the RS off= ers that feature. If the RS does not offer that feature to the RO, then I d= on't think GNAP is very relevant. If the RS restricts the RO's choice of AS= s to a list or federation then GNAP still applies but in this case SSI prin= ciples are likely being trampled. I do not understand the rest of this section. Seems out of scope. 3. The RQ relationship with the RS is _not_ delegation. It is authorization= . This is true whether the RQ happens to be the RO or a separate party. I c= onsider the RQ - RS relationship to be mediated by a Client, not a user age= nt. This is what i call an embedded interaction. RQ signs a VP (containing an a= uthorization - VC) and hand it over to the Client, so the client can use it= to fetch a resource at the RS. In some cases, the RQ user agent is also their client but I hope that GNAP = never makes this assumption. Yes. But in an abstract protocol flow, they should be represented as distin= ct roles. In other words, the party that interacts with the AS may not be the same as= the party that interacts with the RS because we want to encourage the abil= ity for the RQ to delegate to another end user and the client of that end u= ser. This is critical to effective workflows in the real world. Dies delegation might be critical. I will skip it for now and stay focus on= the core topic (direct & embedded interaction) 4. This raises issues around the responsibility of the RS to honor their co= mmitment as a delegate of the RO while also supporting legitimate privacy i= nterests of the RQ or the delegate of the RQ as well as jurisdictional mand= ates that could force the RS to disregard a valid authorization token ("exp= ort restriction") or accept an authorization token that was not rooted in t= rust of the AS ("break the glass"). Same as above, not relevant for this discussion. To summarize, GNAP _should_ deal with delegation as distinct from authoriza= tion. Some aspects of delegation _may_ be out of band for GNAP because GNAP= is an authorization protocol. The case of an authorization token being par= t of a delegation chain _should not_ be precluded by GNAP. This is the core of what we shall be talking about and a very important poi= nt to be noted by the authors: auth vs. delegation. Nevertheless, GNAP IMHO= is a grant negotiation protocol! If this is the case, direct and delegated= authorizations must be addressed. The transport and API between a user agent and an AS and a user agent and a= n RS are not a matter of authorization and, although critically important, = might not need to be specified by GNAP. If this is the case, GNAP will be very simple. Is this the case in the curr= ent draft? I've not used any SSI terminology above. Can you help me understand what SS= I, banking, or other use-cases I may be missing? Let me bring the keywords and let web search do the work: Banking: EBICS -> Protocol used in the banking world relying on public key crypto = for the production and transport of authorizations. RO can sign a payment r= equest and hands it over to a Client (Processor). Client will sign request = and hand it over to the RS (bank). Bank will execute the RO payment request= . This is an embedded interaction. No AS. Is there any Grant Negotiation? N= ot Sure. I think yes. Is this in the scope of GNAP? Not sure. EMV-Chip-Card (you are surely carrying one). RO (bearer) will put in the = POS-device of the merchant (RQ). Smart card will sign a payment and hands o= ver the cryptogram to the merchant device. Merchant device will send crypto= gram to the card processor (Client). The Client will forward request to the= RS (bank) for execution. Bank will confirm the payment. SSI Wallet -> Self Sovereign Identity Maybe too new to be addressed. We might have some examples in the GNAP us= e case repository. A web search will give you better examples than what i c= an write here. /Francis On Wed, Feb 24, 2021 at 8:15 PM Francis Pouatcha > wrote: Justin, Adrian, in my initial contributions, I did refer to SSI just as a sample use case u= ser device generated token. We have a lot of example out there running with= Fido, EMV, electronic id cards, passports. Focus on the SSI philosophy might distract from the main issue: having user= device generated cryptograms. Nevertheless, SSI is a good framework to present the use case. Let distinguish between: - a verifiable credential (VC) and - a verifiable presentation (VP). A VC might be produced by an authority (let assume an AS) in a direct negot= iation between RO and AS. No involvement of the Client. I will call this a= direct interaction. The VP is produced by the RO and presented to the Client. No involvement of= the AS. This is also a direct interaction. The presentation of this original RO produced VP by a Client to an RS might= require a new presentation produced by the Client and warping the origina= l VP. I call this an embedded interaction. I am missing this one in GNAP. The =91Embedded=92 suggestion did not make it pass the initial discussion, = because we were unable to justify it legitime use to the OAuth legacy folks= . We have been using this interaction mode in the banking world for the las= t 20 years through diverse protocols. By adopting the embedded interaction, GNAP bridges the way to SSI. Please to not talk about =93embedding user password=94 a la =93password gra= nt=94. I am referring to allowing a client carry a cryptogram produced by t= he RO to the RS. If we define the producer of the Token to be an AS, the we will have to sho= w a mortal how to run the http based A-(Server) on the user device. Even if we narrow the definition of the AS to producing the VC and not the = VP, we still have a problem, as some VC might be produced by the user. In the EU we will be witnessing eIDAS certificates issued to user, allowing= them to produce their own VC, without the help of server based AS? Shall t= his make those VC producing applications running on the user device AS? The= n we will have to redefine AS. /Francis ________________________________ From: Francis Pouatcha > Sent: Thursday, February 25, 2021 1:13 AM To: Justin Richer >; Adrian Gropper= > Cc: Francis Pouatcha >; Denis >; txauth gnap > Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI Justin, Adrian, in my initial contributions, I did refer to SSI just as a sample use case u= ser device generated token. We have a lot of example out there running with= Fido, EMV, electronic id cards, passports. Focus on the SSI philosophy might distract from the main issue: having user= device generated cryptograms. Nevertheless, SSI is a good framework to present the use case. Let distinguish between: - a verifiable credential (VC) and - a verifiable presentation (VP). A VC might be produced by an authority (let assume an AS) in a direct negot= iation between RO and AS. No involvement of the Client. I will call this a= direct interaction. The VP is produced by the RO and presented to the Client. No involvement of= the AS. This is also a direct interaction. The presentation of this original RO produced VP by a Client to an RS might= require a new presentation produced by the Client and warping the origina= l VP. I call this an embedded interaction. I am missing this one in GNAP. The =91Embedded=92 suggestion did not make it pass the initial discussion, = because we were unable to justify it legitime use to the OAuth legacy folks= . We have been using this interaction mode in the banking world for the las= t 20 years through diverse protocols. By adopting the embedded interaction, GNAP bridges the way to SSI. Please to not talk about =93embedding user password=94 a la =93password gra= nt=94. I am referring to allowing a client carry a cryptogram produced by t= he RO to the RS. If we define the producer of the Token to be an AS, the we will have to sho= w a mortal how to run the http based A-(Server) on the user device. Even if we narrow the definition of the AS to producing the VC and not the = VP, we still have a problem, as some VC might be produced by the user. In the EU we will be witnessing eIDAS certificates issued to user, allowing= them to produce their own VC, without the help of server based AS? Shall t= his make those VC producing applications running on the user device AS? The= n we will have to redefine AS. /Francis From: Justin Richer > Date: Wednesday, February 24, 2021 at 1:58 PM To: Adrian Gropper > Cc: Francis Pouatcha >, Denis >, txauth gnap > Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI +1 to this. In my opinion, building on anything other than HTTP right now i= s speculation, at best. And building an abstraction from zero-to-one concre= te manifestations is a recipe for disaster. Once a second thing comes along= , you inevitably realize that you put the abstraction points in the wrong p= lace and have in fact baked in a lot of assumptions about your base case in= to what was supposed to be an abstraction layer. Instead, if there=92s a desire to build out GNAP on top of other protocols,= then it should be :translated: to those protocols. This happened with OAut= h being built on top of COAP in ACE, without OAuth defining an abstraction = layer ahead of time. And I=92ll wager that if we had defined such a layer, = it would not have considered things like the multi-tiered client structures= that are in ACE, or the key distribution challenges in the IoT environment= . Abstractions can come after the fact to aid future translations, but tran= slation is nearly always more practical. But my point in starting this thread is that I think we can set up appropri= ate extension points for novel elements without throwing out the entire bas= e protocol, or creating something overly abstract. So I think we can keep t= he =93AS=94 component and the central HTTP-based protocol but have places w= here these other elements, like SSI wallets, can come in. I think we need t= o get away from the false conclusion that the SSI wallet has to :be: the AS= . Instead, I think the SSI wallet can feed information into an AS in order = for the AS to do its job. =97 Justin On Feb 24, 2021, at 12:47 PM, Adrian Gropper > wrote: It might help the GNAP scoping discussion relative to SSI if we consider tw= o separate domains: - Registration: The relationship between the RO and the RS prior to any GNA= P Client entering the picture, and - Authorization: The interaction protocols between the user agents of end u= sers and servers Fact: Only two SSI standards (VC and DID) are established enough for us to = reference in GNAP and they are both merely data models, not protocols. Neit= her of these data models is particularly concerned with delegation protocol= s although there is going to be some impact from things like multi-signatur= e schemes and filtering of capabilities. IMHO, GNAP as a delegation protocol standard cannot presume the success or = applicability of any SSI inspired protocols, including DIDcomm or Confident= ial Storage, that are still trying to figure out their relationship to HTTP= . Also, IMHO, SSI is not synonymous with protocols that presume a Holder as a= mandated intermediary store for any attribute that moves between an issuer= and a verifier. There are many, maybe most, use cases where SSI would be b= etter served by control of the attribute over actual possession of the attr= ibute. Adrian On Wed, Feb 24, 2021 at 12:09 PM Francis Pouatcha > wrote: Integrating GNAP and SSI requires a lot of fundamentals: * AS had their essence in the fact that human held devices were not abl= e to produce authorization sharable to client and RS * If the human held device can do the work, it is natural the momentum = will shift in that direction. This is what is happening with SSI. * Sharing all views of Adrian mention in this thread(no need to repeat)= . * But repeating the keyword: ZTA. Keeping custodian, server centered ar= chitectures under control is getting tougher as time goes by. In GNAP initial discussion, we walked through a lot of abstract diagram, th= at could have allowed production of authorization and authentication materi= al (token) by human held devices. The intention was inspired from SSI discu= ssions. IF Justin is asking to reconsider an integration of SSI, THEN we need to review the abstract protocol flows: * roles * entities * relationships We will have to start by taking the http protocol constraint out of the cha= rter. BTW * I agree with Justin: "The RS decides on how to consume a presented to= ken." * I agree with Denis: "AS plays no role and shall have no influence on = the RS decision on how to consume a token." THEN We must start by sharping the meaning of an AS (in the context of GNAP). Di= scussion might lead to a retirement of this term. As mortals might have a h= ard time considering a user held device a server. END IF Nevertheless, the transition from (http)-AS based token production to user = device-based token production will need some 10+ years to complete. Still a= lot of challenges around how to protect keys held on user devices against = damage, loss of device, malware, ransomware, social engineered attack. Can GNAP be the main vehicle for this transition? Maybe. Despite the (too) = strong reliance on the OAuth legacy (even if GNAP does not promise backward= compatibility to OAuth), an embedded interaction that allows the client to= carry the user device produced token to the resource server might pave way= for this transition. I campaigned for consideration of an embedded interac= tion in the initial conversation. I am not sure this was taken into account= . Still must find time to review the current draft. /Francis ________________________________ From: TXAuth > on b= ehalf of Denis > Sent: Tuesday, February 23, 2021 12:51 PM To: Justin Richer >; txauth gnap > Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI Hi Justin, See my comments between the lines. An important aspect in the discussion here, that I agree with, is that the = RS needs to be able to decide which AS it talks to. While I would agree with such a sentence in the OAuth WG, I don't believe = that this sentence is applicable in general in the context of GNAP. A RS does not need to "talk to" any AS. A RS decides which AS(s) it trusts = to issue access tokens that contains some set of privileges. But inherent in that is that it=92s not the user=92s decision, or the AS=92= s decision, it=92s the RS=92s decision who it will trust to get tokens from= . A RS does not necessarily need to trust all the access tokens issued by a g= iven AS, but only access tokens from a given AS that contain a given set of privileges. And no matter what our philosophy, at the end of the day the RS will always= have the choice of whether to trust an inbound request. Not exactly: the RS will apply the rules given by the RO. Which is why, to me, this really brings us to the question of what an AS pr= ovides. The AS gives the RS a token that the RS decides to trust, and that the RS can understand (either directly with something like JWT or = indirectly with something like introspection). But the AS also needs to decide what to put INTO that token. As a consequen= ce, the AS can get that information from any number of places. The information could be provided in a trusted way by the end user to the A= S =97 but this does NOT necessarily mean that the AS belongs to the user or is under their control. Basically, I think we=92re trying to hard to map the OAuth general-concept = of the RO having an account at the AS and logging in to it before authorizi= ng the request. I think that the call for =93every user to have their own AS=94 is such a h= uge non-starter in so many domains that it hampers the solution space if th= at=92s what we presume. It=92s up to the RS to decide who it trusts, not the end user and not the R= O. I think we should ALLOW it, and we can be clearer in GNAP that that=92s one= possible model, but not the only one, and not even the general one. The AS manages all of the information and interconnections needed to create= an access token that the RS will accept, and it is in charge of signaling = to the RS what that token=92s good for. I disagree: the AS is NOT in charge of signaling to the RS what that token= =92s good for. It is up to the RS to decide which privileges it will accept among all the privileges included into an access token. However, if the AS can learn through some other means that a specific ident= ified user has consented and provided appropriate information in a trusted = way, then THAT information can be baked into the token by the AS. =97 importantl= y, in a way that the RS=92s the AS protects can understand. I disagree: Trust relationships are not bilateral but only unilateral. An A= S does not need to have any specific prior relationship with a given RS. It is up to the RS(s) to decide which AS(s) it trust(s) and for which privi= leges. This last bit is where general opacity of tokens is important here. There= =92s a natural security boundary that arises from this model. What I=92m pr= oposing here is just that we=92re more explicit about what can be put INTO = that boundary. That=92s where I=92m seeing a lot of this innovation in the = SSI space fitting. You=92re not coming up with some universal access token = that the RS will accept, but you=92re able to provide universal claims and = artifacts that an AS can process and translate into a token the RS will acc= ept and do the right thing with. Your argumentation about token opacity is making the assumption that the AS= and the RS need to have a prior relationship before any access can take pl= ace. While this was valid with OAuth, this is no more valid in the context of GN= AP. The client should be able to inform the AS about the access token form= at(s) acceptable to the RS. Then the client may indicate to the AS these acceptable formats. If the RS = and the AS have an access token format in common, then the process may cont= inue. When only attributes (i.e. not rights) are being requested to an AS by the = client, the client does not need to disclose the identity of the RS to the = AS, which has the major advantage to prevent the AS to act as Big Brother. Note: this does not preclude the use of rights, in particular in the co= ntext of a single organization or enterprise. Denis =97 Justin On Feb 21, 2021, at 9:40 AM, Adrian Gropper > wrote: Hi Torsten, Thank you for raising all of these excellent points. I hope we can all answ= er them and maybe even add a section to the wiki. I'll start... You're right that OAuth deployments almost exclusively put the AS and RS in= the same domain. If OAuth were adequate to today's needs we probably would= not be here doing GNAP. Since OAuth, we have increasing privacy concerns a= nd security disasters. GDPR, for example, separates the role of a data cont= roller from a data processor and treats them as separate legal entities. To= oversimplify GDPR, the data processor is spared privacy responsibility and= cost. You are also right to mention open banking as a use-case. Open banking has = not adopted UMA 2.0 (on which I have worked for almost a decade) which is b= ased on OAuth. PSD2 and similar regulations do not tie the AS and RS to the= same security domain but they presume a narrow federation of licensed (and= regulated) ASs as payment processors for subjects to choose among. This ce= ntralization to regulated fiduciaries is a privacy trade-off that makes sen= se in banking. The fiduciary can be bonded so they can refund the money to = the subject in case of a security breach. This privacy-security tradeoff do= es not make sense in healthcare and other domains where the consequences of= a breach are not easily reversed. This thread is about aligning GNAP and SSI. SSI does not abide centralizati= on, censorship, or surveillance. If GNAP makes any assumptions that result = in either a tight coupling between AS and RS (surveillance) or even a feder= ated fiduciary (centralization) we will lose out on the benefits of progres= s in digital identity that is now driving a lot of public-sector initiative= s and starting to bleed over into private sector practices. Zero Trust Arch= itecture is an example and OAuth is not well suited for ZTA. As you said, "technically, the respective AS and RSs set up a trust relatio= nship and agreed on ways to share authorization and user data in order [to]= enable secure API access." This is where GNAP operates and we need to avoi= d _any_ restrictions on either the AS or the RS being self-sovereign. Examp= les of a self-sovereign RS could be a personal data store or an encrypted d= ata vault like the ones we work on in W3C/DIF. Any AS can be self-sovereign= if the subject controls all of the policies and these policies are not sha= red, in the same way a private key is never not shared. Continuing your quote: I read your ideas regarding self-sovereign ASs with great interest and got = some observations/questions: - A personal AS could certainly control access to a person=91s resources. I= assume the person=91s RSs would only accept access tokens signed by the RO= . Am I right? Yes, and. There is debate in various SSI WGs whether a RS such as an Encryp= ted Data Vault should respond to capabilities or tokens. Either way, the RO= is in control of the signature but a personal AS is a delegate of the RO (= either directly or via a mobile user agent). With capabilities such as ZCAP= -LD or biscuits, the token signature allows for filtered delegation. - Do you envision this AS to be able to control access to any kind of RS? H= ow is the AS supposed to know what authorization data this RS needs in orde= r to perform access control decisions? What data will be exchanged? Yes. The whole point, as far as I'm concerned, is to design human centered = standards. This is how W3C and IETF are different. Other SDOs tend to be op= erated for institutional benefit. A person-centered AS must work across ins= titutional domains. This, as you point out, brings up the problem of scope. Ontologies and data= models are, justifiably, domain-specific. I, for example, work around the = HL7 data model standards and APIs like FHIR that are controlled by healthca= re business interests. It's unreasonable to expect a general solution to th= e data model problem, although folks of the Linked Data persuasion might di= sagree. Every RS gets to decide what data models and ontologies it supports. These = decisions are public and sometimes standardized for the benefit of the clie= nts. A person's AS must read and maybe understand the RS data model in orde= r to issue tokens just like the client needs to do in order to make a reque= st to the AS. In our HIE of One Trustee project, we allow the self-sovereig= n subject to inherit AS policies from self-sovereign communities they choos= e and then modify the policies if they want. In this way, communities compe= te for members on the basis of policy bundles the same way churches compete= for congregants. - How would this person delegate access to her resources to someone else? There are two "persons" to consider. The RO delegates to an RQ. But the RQ,= in real life, is part of a team and often delegates to associates. With or= without capabilities, GNAP needs to deal with this reality that RO and RQ = user agents may be different from the client that actually presents a token= to the RS. Some of this difference between user agents and clients we may = be able to keep out of band. - Are you aware of deployments implementing this philosophy? Other than our HIE of One demonstration project in healthcare, no. We start= ed HIE of One before SSI in order to drive the transition from UMA to UMA 2= .0 and inform various healthcare regulatory priorities. We then jumped on S= SI immediately and added it to the UMA 2 AS we call Trustee. Now we are try= ing to align SSI and GNAP in order to enable human-centered protocols and z= ero-trust architecture. - What are the implications in terms of user experience? Right now, the human-centered user experience assumes a secure element and = web browser as user agents on a mobile device. Neither of these is readily = accessible as a server nor are they designed to accept code plug-ins that r= epresent the policies of an AS. One major exception is people adding advert= ising and surveillance blockers like EFF Privacy Badger to their browser. The user experience implications of having SSI data model standards and GNA= P protocol standards is that today's password managers (I have 250 RS relat= ionships in mine) will evolve to also control an AS agent. Just like I migh= t register a W3C DID with an RS instead of an email address, my policy mana= ger might display to me the token policies that will be applied by my AS to= the personal data I can control at that RS. In some cases, my AS will allow me to modify those policies just like the o= bnoxious cookie policy settings do today. The BIG difference with GNAP is t= hat I choose my AS separately from the RS so the dark patterns associated w= ith today's cookie policies experience are no longer possible. GNAP means t= he RS exposes an API rather than a UI. I've gone on far too long to address the issue of the AS as an identity pro= vider. It's fair to think of it that way. As it turns out, in the SSI Secur= e Data Storage WG, we are debating the difference between an Encrypted Data= Vault and an Identity Hub. As far as I'm concerned, the Identity Hub is mo= stly a GNAP AS. Join us on Thursdays at 4 PM ET https://lists.identity.foun= dation/g/sds-wg/wiki/Home Adrian On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt > wrote: Am 19.02.2021 um 23:50 schrieb Adrian Gropper >: ? I agree with the first two of Justin's responses but not the last one. It's confusing to think that there are more RS than AS. the OAuth deployments I=91m aware of typically have much more RSs than ASs.= Why? Because AS and a set of RSs belong to the same security domain (e.g. = a certain business) and it=92s the AS=92s responsibility to ensure secure a= nd convenient access to the APIs provided by this RSs. For example: there i= s a AS controlling access to a cloud, streaming, and messaging services of = the same business. In case of open banking, the bank=91s AS is (on behalf o= f the user) authorizing access to APIs for account information as well as p= ayment initiation and potentially other services. Technically, the respective AS and RSs set up a trust relationship and agre= ed on ways to share authorization and user data in order enable secure API = access. I read your ideas regarding self-sovereign ASs with great interest and got = some observations/questions: - A personal AS could certainly control access to a person=91s resources. I= assume the person=91s RSs would only accept access tokens signed by the RO= . Am I right? - Do you envision this AS to be able to control access to any kind of RS? H= ow is the AS supposed to know what authorization data this RS needs in orde= r to perform access control decisions? What data will be exchanged? - How would this person delegate access to her resources to someone else? - Are you aware of deployments implementing this philosophy? - What are the implications in terms of user experience? In my experience coupling between AS and RS is very tight. I have a hard ti= me to see how self-sovereign ASs would work. It feels like such an AS in th= e end is an identity provider of some sort, which brings me to what Justin = proposed. I would assume using SSI credentials to authenticate towards ASs = is feasible and might have value but I=91m skeptical about the AS part. best regards, Torsten. >From a human-centered (and hopefully IETF) perspective, each person might c= ontrol or specify a different AS for each of their personas or for each chi= ld or incompetent delegate of them as guardian. We're familiar with separat= e gmail addresses for each persona. ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial bitcoi= n wallet), or brokers (as in data brokers and surveillance capitalism). Any= RS that is willing to have a recurring relationship with a persona could a= ccept a GNAP AS endpoint instead of an email address. This is easiest using= HTTP, but GNAP need not exclude other RS / AS APIs and transports. Designi= ng around the uncensored specification of one's AS as a human right would g= reatly simplify many aspects of GNAP adoption. That said, GNAP should not ignore the RS business or jurisdictional reasons= to limit the authority of the AS. UMA 2.0 spent years dancing around this = issue with ideas like "cascading" AS and various centralized or federated A= S concepts. My conclusion is that any RS can always do whatever it wants an= d there's not much the authorization protocol can help with other than spec= ifying a notification endpoint so that an RS can warn (and seek confirmatio= n) or log various exceptions. This turns out to be, after a year of testimo= ny, the regulation that applies to HIPAA RS APIs in the US. For this reason= GNAP might include a notification protocol in the AS specification, or not= . I propose that embracing a self-sovereign agent is key to harmonizing the S= SI and GNAP standards. Adrian On Fri, Feb 19, 2021 at 2:30 PM Justin Richer > wrote: Tobias, thanks for the great observations. Some reactions inline below. On Feb 18, 2021, at 7:59 PM, Tobias Looker > wrote: Justin, I think this is a great and timely conversation to be having given the curr= ent interest around SSI and efforts like SIOP, I have been doing quite a bi= t of work in this space as of recent, so thought I'd add a few of the obser= vations that I've made. In my opinion SIOP was really a bucket for solving quite a few different pr= oblems, not just one. In particular I think its intent was to solve 3 major= ones: 1. Enabling portable identities 2. Solving the NASCAR problem 3. Exploring different deployment models for the provider To drill down briefly on these, note much of my terminology is OpenID based= due to SIOPs origin Enabling portable identities - In general today in the case of OpenID, the = end-users identity as understood by a relying party is scoped within the do= main of the provider. Which means if that provider goes out of business or = for whatever reason decides to no longer offer the same identity services t= o the End-User, their identity is essentially gone. Whilst there has been s= ome interesting related work from groups like MODRNA on solutions to combat= this like 'Account Porting', they often assume the old provider remains on= line and willing to facilitate in the account porting process so that the E= nd-User can migrate to a new provider. SIOP actually elected to do somethin= g different here by using cryptography, instead of the End-User identifier = being something like a GUID asserted within the domain of the provider, SIO= P defined this instead as a public key fingerprint associated to a private = key that's assumed to be under the control of the user. In doing so the ide= ntity itself becomes portable between providers by transferring the associa= ted private key. Now this approach does have drawbacks and arguably encoura= ges what many would refer to as bad cryptographic practise by not allowing = any way to do key rotation, however the idea was there. How GNAP can solve for this? By having flexibility around how the resource = owner / End-User is referred to by the Authorization server (e.g allow the = identifier to be something like a public key or a resolvable identifier to = public keys such as a DID) I personally think that GNAP should be a flexible :carrier: of identifiers = and other bits of identity information. This is the main reason we went wit= h the Subject Identifiers draft from SECEVENT: it=92s set up to talk about = a variety of different kinds of identifiers, all of them asserted in the co= ntext of the AS. If there=92s a definition for a DID URL or a JWK in the su= b_ids object structure, GNAP would be able to just use it directly alongsid= e every other format. I haven=92t seen those proposed yet, but it would be = easy to do and, in my mind, would be a better solution than the portable id= entifiers proposal that was recently brought up in the FAPI working group i= n OIDF. (A side note, but the main problem I have here is that it=92s pasti= ng semantics and formats onto a field where none existed before, and that= =92s rife for problems. Better to have a structure that takes that into acc= ount from the start, in my view.) Solving the NASCAR problem - One of those enduring problems in identity sys= tems, which I think is really about the three way negotiation going on betw= een the RP, the End-User and the Provider. SIOP's solution pushed for most = of the power in this decision making process to lie with the End-User, lett= ing them decide who they want as their provider rather than RP's providing = an enumeration of who they support via provider icons on their login page a= nd End-Users having to select from those options. It accomplished this via = using a custom URL scheme of `openid://` where the End-User would register = their chosen provider as a protocol handler for the `openid://` scheme. How= ever, again as a solution it's not without it's challenges, notably; only a= single registration at a time can be supported, the actual identity of the= provider remains blind to the RP until after the request is sent and it re= quires registration or some form of default handling (e.g when there is no = provider registered). How GNAP can solve for this? I actually don't think this is core to GNAP, t= here may be some considerations around discovery that are worth paying atte= ntion to but not much in the core protocol design. SIOP doesn=92t really solve the NASCAR issue since SIOP, by design, becomes= yet one more login option among many. I think GNAP can help this by enabli= ng user-directed provider discovery to kick off the process, but I agree th= at the core protocol doesn=92t really have much to say here, and shouldn=92= t. Exploring different deployment models for the provider - This is the most f= requently talked about aspect of SIOP and perhaps the most interesting to G= NAP. I like to think about the scope of this issue as designing to allow fo= r either a partially or fully distributed/decentralized provider, rather th= an a centralized one (e.g an HTTP based AuthZ server). As you noted this do= es come with its challenges many of which are technical in nature, i.e how = to appropriately address a decentralized provider and what protocols are us= ed to communicate with the provider. How GNAP can solve for this? I think that's what much of the discussion on = this thread will be about and whether there is a hybrid model where some re= sponsibility is still centrally administered like token issuance, while all= owing other aspects to occur in a more distributed manner. Ideally though I= 'd like to see consideration for a completely distributed model too. I agree that this seems to be the most interesting place for overlap. I don= =92t actually think the =93hybrid=94 approach centralizes things. Instead, = you can think of the RS as having an associated AS, and that AS accepting u= ser consent and claims at runtime from a variety of sources (wallets, VCs, = etc.). In this way, we aren=92t talking about a single AS in the world hand= ling all of these requests, we=92re talking about a distributed network of = AS=92s associated with an even more widely distributed set of RS=92s. SSI a= nd its associated technologies would help these =93local=94 AS=92s issue ac= cess tokens without the RO needing to have an account, or even necessarily = directly interacting with the AS. There=92s currently a technology gap ther= e, but my thoughts are that this is where the changes to the interaction mo= des section can really come to play. I think the notion of a non-HTTP AS is interesting, but I=92m not sure if t= hat=92s something GNAP ought to be solving for. I think that there=92s a de= ep value in building on top of HTTP for the core protocol, and not abstract= ing away concepts from it. Otherwise, you end up re-inventing layers, and y= ou get something like SOAP all over again. :) =97 Justin Thanks, [Mattr website] Tobias Looker Mattr +64 (0) 27 378 0461 tobias.looker@mattr.global [Mattr website] [Mattr on LinkedI= n] [Mattr on Twitter= ] [Mattr on Github]= This communication, including any attachments, is confidential. If you are = not the intended recipient, you should not read it - please contact me imme= diately, destroy it, and do not copy or use any part of this communication = or disclose anything about it. Thank you. Please note that this communicati= on does not designate an information system for the purposes of the Electro= nic Transactions Act 2002. On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault > wrote: Hi Justin, I agree that defining AS role primarily as a token issuer is a fruitful ide= a. Solving this problem well would also respond to the challenges discussed= previously on the list. Cheers Fabien Le mer. 17 f=E9vr. 2021 =E0 23:27, Justin Richer > a =E9crit : The last interim call had a lot of discussion on SSI technologies such as d= igital wallets, and how those fit with GNAP. I think it=92s worth continuin= g that conversation here on the list. There are a few issues in the tracker= that give some background, too: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 There=92s been a lot of interesting work recently in the OpenID Foundation = around using the Self-issued OP (SIOP) functionality to bootstrap an SSI st= yle login. This makes extensive use of the implicit flow and front channel = messaging, but minimization of the front channel for message passing is a k= ey design tenet of GNAP (so much so that it=92s included in our charter). I= nstead, GNAP has been built around an idea that everything starts the same = way: with an HTTP request to the AS. The idea of an on-device AS has been brought up a lot, and we need to consi= der if and how we want to deal with these kinds of use cases. The most obvi= ous way to address these would be to do some kind of clever off-HTTP hack l= ike SIOP, but keep in mind that even SIOP generally starts off with an HTTP= -based discovery call by the RP to make things work. My personal stance is that to do this, we need to re-evaluate our assumptio= ns about exactly what an AS does and what it needs to do those things. In O= Auth 2, it=92s assumed that the AS is the device that=92s authenticating th= e user, collecting consent, managing the client=92s registration, and creat= ing an access token based on whatever set of rights that are associated wit= h all of those things. In UMA, this is turned around a bit by letting the R= O present a bunch of nebulous =93claims=94 interactively, but still at the = AS. With both of these, a key aspect remains: the AS needs to gather necessary = information, and issue the access token (or identifiers/assertions). Becaus= e of how the protocol works, the client software now has a better opportuni= ty to present information to the AS, either directly in the request or by i= ntroducing the AS to another software component during the =93interaction= =94 phase. So, what if we think of the AS primarily as a =93token issuer=94= ? For example, if the client can present a verifiable credential (VC) that re= presents the end user, the AS can validate that VC and make an access token= on behalf of that user, without having the user log in or interact with th= e AS at all. This VC can contain whatever access rights the token needs to = represent, and the AS can translate that into an artifact that the downstre= am RS=92s can interpret, without having to see the original VC or the user = at all. The AS is still HTTP based, but all the essential security and righ= ts elements are provided by the wallet. In this way, we can expand on the p= rivacy-preserving aspects of OAuth and bridge the worlds of SSI and web API= s without violating the basic nature of either. Coming from the OAuth world, it feels weird to issue tokens like this, but = there=92s precedent for this kind of thing. Today, a there are a number of = service-based OAuth AS's that are told what claims need to get put into the= access token by some trusted component. All of this happens outside the OA= uth protocol. In GNAP, I think it makes sense to account for this kind of t= hing in how we define the protocol. That isn=92t to say all of these pieces= need to be defined in the core, but the base protocol ought to be able to = handle being extended in this direction as needed. I=92m really interested to hear other people=92s thoughts on how this could= come together. =97 Justin -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth This communication, including any attachments, is confidential. If you are = not the intended recipient, you should not read it - please contact me imme= diately, destroy it, and do not copy or use any part of this communication = or disclose anything about it. Thank you. Please note that this communicati= on does not designate an information system for the purposes of the Electro= nic Transactions Act 2002. -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- TXAuth mailing list TXAuth@ietf.org https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth= &source=3Dgmail-imap&ust=3D1614379828000000&usg=3DAOvVaw3avsUGQ48fo1OUQV0vy= yKd -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth --_000_FR2P281MB01385E9064D7D5F70B09DEAA8D9E9FR2P281MB0138DEUP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    Adrian, inline,
    I deeply want to understand what use-cases GNAP may be missing but I'm= having trouble understanding your requirement and don't have the benefit o= f banking world experience. It doesn't matter to me whether GNAP is mi= ssing a use-case related to SSI or not. I just want to understand any limitations we might be building i= nto GNAP 1.0

    I hope some of this helps us come to a common vocabulary...

    1. I think in terms of delegation. The GNAP AS is a delegate of the RO= . The RO (or RQ) uses a user agent to interact with the AS. This user-agent= could be a web browser or a mobile app. I assume that users can choose use= r agents that include a HSM such as a FIDO2 or SIM card and I hope that's encouraged but if an AS wants to = deal with username / password, I would not prohibit that.

    This is correct. What is we have a RO/RQ that doesn't need delegation?= Delegation is only necessary is RO/RQ does not have the capability needed = to the work. If RO/RQ can generate the token, we do not need to delegate to= the AS.
    2. The RS is another kind of delegation.
    Yes. RS are delegate in that they= manage resources on behalf of RO. 

    As with the AS, the RO can approach the RS directly with a user agent = and exercise their privilege of specifying an AS as their delegate if the R= S offers that feature. If the RS does not offer that feature to the RO, the= n I don't think GNAP is very relevant. If the RS restricts the RO's choice of ASs to a list or federation then GN= AP still applies but in this case SSI principles are likely being trampled.=  
    I do not understand the rest of this section. Seems out of scope.

    3. The RQ relationship with the RS is _not_ delegation. It is authoriz= ation. This is true whether the RQ happens to be the RO or a separate party= . I consider the RQ - RS relationship to be mediated by a Client, not = a user agent.
    This is what i call an embedded interaction. RQ signs a VP (containing= an authorization - VC) and hand it over to the Client, so the client can u= se it to fetch a resource at the RS.

    In some cases, the RQ user agent is also their client but I hope that = GNAP never makes this assumption. 
    Yes. But in an abstract protocol flow, they should be represented as d= istinct roles.

    In other words, the party that interacts with the AS may not be the sa= me as the party that interacts with the RS because we want to encourage the= ability for the RQ to delegate to another end user and the client of that = end user. This is critical to effective workflows in the real world.

    Dies delegation might be critical. I will skip it for now and stay foc= us on the core topic (direct & embedded interaction)

    4. This raises issues around the responsibility of the RS to honor the= ir commitment as a delegate of the RO while also supporting legitimate priv= acy interests of the RQ or the delegate of the RQ as well as jurisdictional= mandates that could force the RS to disregard a valid authorization token ("export restriction") = or accept an authorization token that was not rooted in trust of the AS (&q= uot;break the glass").

    Same as above, not relevant for this discussion.

    To summarize, GNAP _should_ deal with delegation as distinct from auth= orization. Some aspects of delegation _may_ be out of band for GNAP because= GNAP is an authorization protocol. The case of an authorization token bein= g part of a delegation chain _should not_ be precluded by GNAP. 

    This is the core of what we shall be talking about and a very importan= t point to be noted by the authors: auth vs. delegation. Nevertheless, GNAP= IMHO is a grant negotiation protocol! If this is the case, direct and dele= gated authorizations must be addressed. 

    The transport and API between a user agent and an AS and a user agent = and an RS are not a matter of authorization and, although critically import= ant, might not need to be specified by GNAP.

    If this is the case, GNAP will be very simple. Is this the case in the= current draft?

    I've not used any SSI terminology above. Can you help me understand wh= at SSI, banking, or other use-cases I may be missing?

    Let me bring the keywords and let web search do the work:
    Banking:
      EBICS -> Protocol used in the banking world relying on publi= c key crypto for the production and transport of authorizations. RO can sig= n a payment request and hands it over to a Client (Processor). Client will = sign request and hand it over to the RS (bank). Bank will execute the RO payment request. This is an embedded inte= raction. No AS. Is there any Grant Negotiation? Not Sure. I think yes. Is t= his in the scope of GNAP? Not sure.

      EMV-Chip-Card (you are surely carrying one). RO (bearer) will p= ut in the POS-device of the merchant (RQ). Smart card will sign a payment a= nd hands over the cryptogram to the merchant device. Merchant device will s= end cryptogram to the card processor (Client). The Client will forward request to the RS (bank) for execution. = Bank will confirm the payment.

    SSI Wallet -> Self Sovereign I= dentity
      Maybe too new to be addres= sed. We might have some examples in the GNAP use case repository. A web sea= rch will give you better examples than what i can write here.

    /Francis


    On Wed, Feb 24, 2021 at 8:15 PM Fra= ncis Pouatcha <fpo@adorsys.de> = wrote:

    Justin, Adrian, 

     

    in my initial contributions, I did refer to SSI just as a sample use case user device generated token. We h= ave a lot of example out there running with Fido, EMV, electronic id cards,= passports.

     

    Focus on the SSI philosophy might distract from the main issue: having user device generated cryptograms.

     

    Nevertheless, SSI is a good framework to present the use case.

     

    Let distinguish between:

    - a verifiable credential (VC) and

    - a verifiable presentation (VP).

     

    A VC might be produced by an authority (let assume an AS) in a direct negot= iation between RO and AS. No involvement of the Client.  I will call t= his a direct interaction.

     

    The VP is produced by the RO and presented to the Client. No involvement of= the AS. This is also a direct interaction.

     

    The presentation of this original RO produced VP by a Client to an RS might= require a new presentation produced by the Client and warping the  or= iginal VP. I call this an embedded interaction. I = am missing this one in GNAP.

     

    The =91Embedded=92 suggestion did not make it pass the initial discu= ssion, because we were unable to justify it legitime use to the OAuth legac= y folks. We have been using this interaction mode in the banking world for = the last 20 years through diverse protocols.

     

    By adopting the embedded interaction, GNAP bridges the way to SSI.

     

    Please to not talk about =93embedding user password=94 a la =93pa= ssword grant=94. I am referring to allowing a client carry a cryptogram= produced by the RO to the RS.

     

    If we define the producer of the Token to be an AS, the we will have to sho= w a mortal how to run the http based A-(Server) on the user device.<= u>

     

    Even if we narrow the definition of the AS to producing the VC and not the = VP, we still have a problem, as some VC might be produced by the user.

     

    In the EU we will be witnessing eIDAS certificates issued to user, allowing= them to produce their own VC, without the help of server based AS? Shall t= his make those VC producing applications running on the user device AS? The= n we will have to redefine AS.

     

    /Francis

     



    F= rom: Francis Pouatcha <Francis.Pouatcha@adorsys.com>
    Sent: Thursday, February 25, 2021 1:13 AM
    To: Justin Richer <jricher@mit.edu>; Adrian Gropper <agropper@healthurl.com>
    Cc: Francis Pouatcha <fpo@adorsys.de>; Denis <denis.ietf@free.fr>; txauth gnap <txauth@ietf.org>
    Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI
     

    Jus= tin, Adrian,

    &nb= sp;

    in = my initial contributions, I did refer to SSI just as a sample use case user device generated token. We have a lot of example out there runn= ing with Fido, EMV, electronic id cards, passports.

    &nb= sp;

    Foc= us on the SSI philosophy might distract from the main issue: having user device generated cryptograms.

    &nb= sp;

    Nev= ertheless, SSI is a good framework to present the use case.

    &nb= sp;

    Let= distinguish between:

    - a= verifiable credential (VC) and

    - a= verifiable presentation (VP).

    &nb= sp;

    A V= C might be produced by an authority (let assume an AS) in a direct negotiat= ion between RO and AS. No involvement of the Client.  I will call this= a direct interaction.

    &nb= sp;

    The= VP is produced by the RO and presented to the Client. No involvement of th= e AS. This is also a direct interaction.

    &nb= sp;

    The= presentation of this original RO produced VP by a Client to an RS might re= quire a new presentation produced by the Client and warping the  origi= nal VP. I call this an embedded interaction. I am missing this one in GNAP.

    &nb= sp;

    The= =91Embedded=92 suggestion did not make it pass the initial discussi= on, because we were unable to justify it legitime use to the OAuth legacy f= olks. We have been using this interaction mode in the banking world for the last 20 years through diverse protocols.=

    &nb= sp;

    By = adopting the embedded interaction, GNAP bridges the way to SSI.

    &nb= sp;

    Ple= ase to not talk about =93embedding user password=94 a la =93passw= ord grant=94. I am referring to allowing a client carry a cryptogram pr= oduced by the RO to the RS.

    &nb= sp;

    If = we define the producer of the Token to be an AS, the we will have to show a= mortal how to run the http based A-(Server) on the user device.

    &nb= sp;

    Eve= n if we narrow the definition of the AS to producing the VC and not the VP,= we still have a problem, as some VC might be produced by the user.

    &nb= sp;

    In = the EU we will be witnessing eIDAS certificates issued to user, allowing th= em to produce their own VC, without the help of server based AS? Shall this= make those VC producing applications running on the user device AS? Then we will have to redefine AS.

    &nb= sp;

    /Fr= ancis

    &nb= sp;

     

    From: Justin Richer <jricher@mit.edu><= br> Date: Wednesday, February 24, 2021 at 1:58 PM
    To: Adrian Gropper <agropper@healthurl.com>
    Cc: Francis Pouatcha <fpo@adorsys.de>, Denis <denis.ietf@free.fr>, txauth gnap <txauth@ietf.org>
    Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI

    +1 = to this. In my opinion, building on anything other than HTTP right now is s= peculation, at best. And building an abstraction from zero-to-one concrete = manifestations is a recipe for disaster. Once a second thing comes along, you inevitably realize that you put the a= bstraction points in the wrong place and have in fact baked in a lot of ass= umptions about your base case into what was supposed to be an abstraction l= ayer. 

    &nb= sp;

    Ins= tead, if there=92s a desire to build out GNAP on top of other protocols, th= en it should be :translated: to those protocols. This happened with OAuth b= eing built on top of COAP in ACE, without OAuth defining an abstraction layer ahead of time. And I=92ll wager that i= f we had defined such a layer, it would not have considered things like the= multi-tiered client structures that are in ACE, or the key distribution ch= allenges in the IoT environment. Abstractions can come after the fact to aid future translations, but translation is nea= rly always more practical. 

    &nb= sp;

    But= my point in starting this thread is that I think we can set up appropriate= extension points for novel elements without throwing out the entire base p= rotocol, or creating something overly abstract. So I think we can keep the =93AS=94 component and the central HT= TP-based protocol but have places where these other elements, like SSI wall= ets, can come in. I think we need to get away from the false conclusion tha= t the SSI wallet has to :be: the AS. Instead, I think the SSI wallet can feed information into an AS in order f= or the AS to do its job.

    &nb= sp;

    &nb= sp;=97 Justin


    On = Feb 24, 2021, at 12:47 PM, Adrian Gropper <agropper@healthurl.com> wrote:

    &nb= sp;

    It = might help the GNAP scoping discussion relative to SSI if we consider two s= eparate domains: 

    - <= b>Registration: The relationship between the RO and the RS prior to any= GNAP Client entering the picture, and

    - <= b>Authorization: The interaction protocols between the user agents of e= nd users and servers

    &nb= sp;

    Fac= t: Only two SSI standards (VC and DID) are established enough for us to ref= erence in GNAP and they are both merely data models, not protocols. Neither= of these data models is particularly concerned with delegation protocols although there is going to be some impact from t= hings like multi-signature schemes and filtering of capabilities.

    &nb= sp;

    IMH= O, GNAP as a delegation protocol standard cannot presume the success o= r applicability of any SSI inspired protocols, including DIDcomm or Confide= ntial Storage, that are still trying to figure out their relationship to HTTP. 

    &nb= sp;

    Als= o, IMHO, SSI is not synonymous with protocols that presume a Holder as a ma= ndated intermediary store for any attribute that moves between an issuer an= d a verifier. There are many, maybe most, use cases where SSI would be better served by control of the attribu= te over actual possession of the attribute.

    &nb= sp;

    Adr= ian

    &nb= sp;

    &nb= sp;

    &nb= sp;

    On = Wed, Feb 24, 2021 at 12:09 PM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org<= /a>> wrote:

    Integrating GNAP and SSI requires a lot of fund= amentals:

     

    • AS had their essence in the fact that human he= ld devices were not able to produce authorization sharable to client and RS=
    • If the human held device can do th= e work, it is natural the momentum will shift in that direction. This is wh= at is happening with SSI.
    • Sharing a= ll views of Adrian mention in this thread(no need to repeat). <= /li>
    • But repeating the keyword: ZTA. Keeping cu= stodian, server centered architectures under control is getting tougher as = time goes by.

    In GNAP initial discussion, we walked through a= lot of abstract diagram, that could have allowed production of authorizati= on and authentication material (token) by human held devices. The intention was inspired from SSI discussions.&nb= sp;

     

    IF

      Justin is asking to reconsider an integr= ation of SSI,

     

    THEN

    we need to review the abstract protocol flows:<= /span>

    • roles
    • = entities
    • relationships
      • <= /ul>

    We will have to start by taking the http protoc= ol constraint out of the charter.

     

    BTW

    • I agree with Justin: "The RS decides on h= ow to consume a presented token."
    • I agree with Denis: "AS plays no role and shall have no influence = on the RS decision on how to consume a token."

     

    THEN

    We must start by sharping the meaning of an AS = (in the context of GNAP). Discussion might lead to a retirement of this ter= m. As mortals might have a hard time considering a user held device a server.

     

    END IF

     

     

    Nevertheless, the transition from (http)-AS bas= ed token production to user device-based token production will need some 10= + years to complete. Still a lot of challenges around how to protect keys held on user devices against damage,= loss of device, malware, ransomware, social engineered attack.

     

    Can GNAP be the main vehicle for this transitio= n? Maybe. Despite the (too) strong reliance on the OAuth legacy (even if GN= AP does not promise backward compatibility to OAuth), an embedded interaction that allows the client to carry = the user device produced token to the resource server might pave way for th= is transition. I campaigned for consideration of an embedded interaction in the initial conversation. I am not sure this= was taken into account. Still must find time to review the current draft.<= /span>

     

     

    /Francis

     

     

    = From: TXAuth <txauth-bounces@ietf.org> on behalf of Denis <denis.ietf@free.fr>
    Sent: Tuesday, February 23, 2021 12:51 PM
    To: Justin Richer <jricher@mit.edu>; txauth gnap <txauth@ietf.org>
    Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI

    &nb= sp;

    Hi&= nbsp; Justin,

    &nb= sp;

    See= my comments between the lines.

    An = important aspect in the discussion here, that I agree with, is that the RS = needs to be able to decide which AS it talks to.

     While I would agree with such a sentence in t= he OAuth WG, I don't believe that this sentence is applicable in general in= the context of GNAP.
    A RS does not need to "talk to" any AS. A RS decides which AS(s) = it trusts to issue access tokens that contains some set of privileges.

    But= inherent in that is that it=92s not the user=92s decision, or the AS=92s d= ecision, it=92s the RS=92s decision who it will trust to get tokens from.

    A RS does not necessarily need to trust all the acc= ess tokens issued by a given AS, but only access tokens from a given AS tha= t contain
    a given set of privileges.

    And= no matter what our philosophy, at the end of the day the RS will always ha= ve the choice of whether to trust an inbound request.

    Not exactly: the RS will apply the rules given by t= he RO.

    Whi= ch is why, to me, this really brings us to the question of what an AS provi= des. The AS gives the RS a token that the RS decides to trust,
    and that the RS can understand (either directly with something like JWT or = indirectly with something like introspection).
    But the AS also needs to decide what to put INTO that token. As a consequen= ce, the AS can get that information from any number of places.
    The information could be provided in a trusted way by the end user to the A= S =97 but this does NOT necessarily mean that the AS belongs
    to the user or is under their control. 

    &nb= sp;

    Bas= ically, I think we=92re trying to hard to map the OAuth general-concept of = the RO having an account at the AS and logging in to it before authorizing = the request.
    I think that the call for =93every user to have their own AS=94 is such a h= uge non-starter in so many domains that it hampers the solution space if th= at=92s what we presume.
    It=92s up to the RS to decide who it trusts, not the end user and not the R= O. 

    &nb= sp;

    I t= hink we should ALLOW it, and we can be clearer in GNAP that that=92s one po= ssible model, but not the only one, and not even the general one.
    The AS manages all of the information and interconnections needed to create= an access token that the RS will accept, and it is in charge of signaling = to the RS what that token=92s good for.

    I disagree: the AS is NOT in charge of signaling to= the RS what that token=92s good for. It is up to the RS to decide which pr= ivileges it will accept
    among all the privileges included into an access token.

    How= ever, if the AS can learn through some other means that a specific identifi= ed user has consented and provided appropriate information in a trusted way= ,
    then THAT information can be baked into the token by the AS. =97 importantl= y, in a way that the RS=92s the AS protects can understand.

    I disagree: Trust relationships are not bilateral b= ut only unilateral. An AS does not need to have any specific prior relation= ship with a given RS.
    It is up to the RS(s) to decide which AS(s) it trust(s) an= d for which privileges.

    Thi= s last bit is where general opacity of tokens is important here. There=92s a natural secu= rity boundary that arises from this model. What I=92m proposing here is jus= t that we=92re more explicit about what can be put INTO that boundary. That= =92s where I=92m seeing a lot of this innovation in the SSI space fitting. You=92re not coming up with some universal acces= s token that the RS will accept, but you=92re able to provide universal cla= ims and artifacts that an AS can process and translate into a token the RS will accept and do the right thing with= .

    Your argumentation about token opacity is making th= e assumption that the AS and the RS need to have a prior relationship befor= e any access can take place.
    While this was valid with OAuth, this is no more valid in the context of GN= AP.  The client should be able to inform the AS about the access token= format(s) acceptable to the RS.
    Then the client may indicate to the AS these acceptable formats. If the RS = and the AS have an access token format in common, then the process may cont= inue.

    When only attributes (i.e. not rights) are being re= quested to an AS by the client, the client does not need to disclose the id= entity of the RS to the AS,
    which has the major advantage to prevent the AS to act as Big Brother.

        Note: this does not preclude the use of rights, in particular in the= context of a single organization or enterprise.

    Denis

    &nb= sp;

    &nb= sp;=97 Justin


    On = Feb 21, 2021, at 9:40 AM, Adrian Gropper <agropper@healthurl.com> wrote:

    &nb= sp;

    Hi = Torsten,

    &nb= sp;

    Tha= nk you for raising all of these excellent points. I hope we can all answer = them and maybe even add a section to the wiki. I'll start...

    &nb= sp;

    You= 're right that OAuth deployments almost exclusively put the AS and RS in th= e same domain. If OAuth were adequate to today's needs we probably would no= t be here doing GNAP. Since OAuth, we have increasing privacy concerns and security disasters. GDPR, for exam= ple, separates the role of a data controller from a data processor and trea= ts them as separate legal entities. To oversimplify GDPR, the data processo= r is spared privacy responsibility and cost.

    &nb= sp;

    You= are also right to mention open banking as a use-case. Open banking has not= adopted UMA 2.0 (on which I have worked for almost a decade) which is base= d on OAuth. PSD2 and similar regulations do not tie the AS and RS to the same security domain but they presume a na= rrow federation of licensed (and regulated) ASs as payment processors for s= ubjects to choose among. This centralization to regulated fiduciaries is a = privacy trade-off that makes sense in banking. The fiduciary can be bonded so they can refund the money to th= e subject in case of a security breach. This privacy-security tradeoff does= not make sense in healthcare and other domains where the consequences of a= breach are not easily reversed.

    &nb= sp;

    Thi= s thread is about aligning GNAP and SSI. SSI does not abide centralization,= censorship, or surveillance. If GNAP makes any assumptions that result in = either a tight coupling between AS and RS (surveillance) or even a federated fiduciary (centralization) we wi= ll lose out on the benefits of progress in digital identity that is now dri= ving a lot of public-sector initiatives and starting to bleed over into pri= vate sector practices. Zero Trust Architecture is an example and OAuth is not well suited for ZTA.

    &nb= sp;

    As = you said, "technically, the respective AS and RSs set up a trust relat= ionship and agreed on ways to share authorization and user data in order [t= o] enable secure API access." This is where GNAP operates and we need to avoid _any_ restrictions on either the AS or = the RS being self-sovereign. Examples of a self-sovereign RS could be a per= sonal data store or an encrypted data vault like the ones we work on in W3C= /DIF. Any AS can be self-sovereign if the subject controls all of the policies and these policies are not sha= red, in the same way a private key is never not shared. 

    &nb= sp;

    Con= tinuing your quote:

    I r= ead your ideas regarding self-sovereign ASs with great interest and got som= e observations/questions:
    - A personal AS could certainly control access to a person=91s resources. I= assume the person=91s RSs would only accept access tokens signed by the RO= . Am I right?

    Yes= , and. There is debate in various SSI WGs whether a RS such as an Encrypted= Data Vault should respond to capabilities or tokens. Either way, the RO is= in control of the signature but a personal AS is a delegate of the RO (either directly or via a mobile user = agent). With capabilities such as ZCAP-LD or biscuits, the token signa= ture allows for filtered delegation.

    &nb= sp;

    - D= o you envision this AS to be able to control access to any kind of RS? How = is the AS supposed to know what authorization data this RS needs in order t= o perform access control decisions? What data will be exchanged?

    Yes= . The whole point, as far as I'm concerned, is to design human centered sta= ndards. This is how W3C and IETF are different. Other SDOs tend to be opera= ted for institutional benefit. A person-centered AS must work across institutional domains. 

    &nb= sp;

    Thi= s, as you point out, brings up the problem of scope. Ontologies and data mo= dels are, justifiably, domain-specific. I, for example, work around the HL7= data model standards and APIs like FHIR that are controlled by healthcare business interests. It's unreasonab= le to expect a general solution to the data model problem, although folks o= f the Linked Data persuasion might disagree.

    &nb= sp;

    Eve= ry RS gets to decide what data models and ontologies it supports. These dec= isions are public and sometimes standardized for the benefit of the clients= . A person's AS must read and maybe understand the RS data model in order to issue tokens just like the client= needs to do in order to make a request to the AS. In our HIE of One Truste= e project, we allow the self-sovereign subject to inherit AS policies from = self-sovereign communities they choose and then modify the policies if they want. In this way, communities= compete for members on the basis of policy bundles the same way churches c= ompete for congregants.

    &nb= sp;

    - H= ow would this person delegate access to her resources to someone else?

    The= re are two "persons" to consider. The RO delegates to an RQ. But = the RQ, in real life, is part of a team and often delegates to associates. = With or without capabilities, GNAP needs to deal with this reality that RO and RQ user agents may be different from th= e client that actually presents a token to the RS. Some of this differ= ence between user agents and clients we may be able to keep out of band.

    &nb= sp;

    - A= re you aware of deployments implementing this philosophy?

    Oth= er than our HIE of One demonstration project in healthcare, no. We started = HIE of One before SSI in order to drive the transition from UMA to UMA 2.0 = and inform various healthcare regulatory priorities. We then jumped on SSI immediately and added it to the UMA 2 AS we call Tru= stee. Now we are trying to align SSI and GNAP in order to enable human-cent= ered protocols and zero-trust architecture. 

    &nb= sp;

    - W= hat are the implications in terms of user experience?

    Rig= ht now, the human-centered user experience assumes a secure element and web= browser as user agents on a mobile device. Neither of these is readily acc= essible as a server nor are they designed to accept code plug-ins that represent the policies of an AS. One major ex= ception is people adding advertising and surveillance blockers like EFF Pri= vacy Badger to their browser. 

    &nb= sp;

    The= user experience implications of having SSI data model standards and GNAP p= rotocol standards is that today's password managers (I have 250 RS relation= ships in mine) will evolve to also control an AS agent. Just like I might register a W3C DID with an RS inste= ad of an email address, my policy manager might display to me the token pol= icies that will be applied by my AS to the personal data I can control at t= hat RS. 

    &nb= sp;

    In = some cases, my AS will allow me to modify those policies just like the obno= xious cookie policy settings do today. The BIG difference with GNAP is that= I choose my AS separately from the RS so the dark patterns associated with today's cookie policies experience= are no longer possible. GNAP means the RS exposes an API rather than a UI.=

    &nb= sp;

    I'v= e gone on far too long to address the issue of the AS as an identity provid= er. It's fair to think of it that way. As it turns out, in the SSI Secure D= ata Storage WG, we are debating the difference between an Encrypted Data Vault and an Identity Hub. As far as = I'm concerned, the Identity Hub is mostly a GNAP AS. Join us on Thursdays a= t 4 PM ET https://lists.identity.foundation/g/sds-wg/wiki/Home=  

    &nb= sp;

    Adr= ian

    &nb= sp;

    &nb= sp;

    &nb= sp;

    On = Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrot= e:

    &nb= sp;


    Am 19.02.2021 um 23:50 schrieb Adrian Gropper <agropper@healthurl.com>:

    = 5279;

    I a= gree with the first two of Justin's responses but not the last on= e.

    &nb= sp;

    It'= s confusing to think that there are more RS than AS.

    &nb= sp;

    the= OAuth deployments I=91m aware of typically have much more RSs than ASs. Wh= y? Because AS and a set of RSs belong to the same security domain (e.g. a c= ertain business) and it=92s the AS=92s responsibility to ensure secure and convenient access to the APIs provided by this RSs. F= or example: there is a AS controlling access to a cloud, streaming, and mes= saging services of the same business. In case of open banking, the bank=91s= AS is (on behalf of the user) authorizing access to APIs for account information as well as payment initiation and p= otentially other services. 

    &nb= sp;

    Tec= hnically, the respective AS and RSs set up a trust relationship and agreed = on ways to share authorization and user data in order enable secure API acc= ess.

    &nb= sp;

    I r= ead your ideas regarding self-sovereign ASs with great interest and got som= e observations/questions:

    - A= personal AS could certainly control access to a person=91s resources. I as= sume the person=91s RSs would only accept access tokens signed by the RO. A= m I right?

    - D= o you envision this AS to be able to control access to any kind of RS? How = is the AS supposed to know what authorization data this RS needs in order t= o perform access control decisions? What data will be exchanged?

    - H= ow would this person delegate access to her resources to someone else?

    - A= re you aware of deployments implementing this philosophy?

    - W= hat are the implications in terms of user experience?

    &nb= sp;

    In = my experience coupling between AS and RS is very tight. I have a hard time = to see how self-sovereign ASs would work. It feels like such an AS in the e= nd is an identity provider of some sort, which brings me to what Justin proposed. I would assume using SSI cr= edentials to authenticate towards ASs is feasible and might have value but = I=91m skeptical about the AS part.

    &nb= sp;

    bes= t regards,

    Tor= sten.


    Fro= m a human-centered (and hopefully IETF) perspective, each person might cont= rol or specify a different AS for each of their personas or for each child = or incompetent delegate of them as guardian. We're familiar with separate gmail addresses for each persona.

    &nb= sp;

    ASs= will be self-sovereign (as in SSI), fiduciary (as in a custodial bitcoin w= allet), or brokers (as in data brokers and surveillance capitalism). Any RS= that is willing to have a recurring relationship with a persona could accept a GNAP AS endpoint instead of an = email address. This is easiest using HTTP, but GNAP need not exclude other = RS / AS APIs and transports. Designing around the uncensored specification&= nbsp;of one's AS as a human right would greatly simplify many aspects of GNAP adoption.

    &nb= sp;

    Tha= t said, GNAP should not ignore the RS business or jurisdictional reaso= ns to limit the authority of the AS. UMA 2.0 spent years dancing around thi= s issue with ideas like "cascading" AS and various centralized or federated AS concepts. My conclusion is that an= y RS can always do whatever it wants and there's not much the authorization= protocol can help with other than specifying a notification endpoint so th= at an RS can warn (and seek confirmation) or log various exceptions. This turns out to be, after a year of testimony= , the regulation that applies to HIPAA RS APIs in the US. For this reason G= NAP might include a notification protocol in the AS specification, or not.<= /p>

    &nb= sp;

    I p= ropose that embracing a self-sovereign agent is key to harmonizing the SSI = and GNAP standards.

    &nb= sp;

    Adr= ian

    &nb= sp;

    On = Fri, Feb 19, 2021 at 2:30 PM Justin Richer <jricher@mit.edu> wrote:

    Tob= ias, thanks for the great observations. Some reactions inline below.


    On = Feb 18, 2021, at 7:59 PM, Tobias Looker <tobias.looker@mattr.global> wrote:<= /p>

    &nb= sp;

    Jus= tin,

    I think this is a great and timely conversation to be having given the curr= ent interest around SSI and efforts like SIOP, I have been doing quite a bi= t of work in this space as of recent, so thought I'd add a few of the obser= vations that I've made.

    In my opinion SIOP was really a bucket for solving quite a few different pr= oblems, not just one. In particular I think its intent was to solve 3 major= ones:

    1. Enabling portable identities
    2. Solving the NASCAR problem
    3. Exploring different deployment models for the provider

    To drill down briefly on these, note much of my terminology is OpenID based= due to SIOPs origin 

    Enabling portable identities - In general today in the case of OpenI= D, the end-users identity as understood by a relying party is scoped within= the domain of the provider. Which means if that provider goes out of busin= ess or for whatever reason decides to no longer offer the same identity services to the End-User, their ident= ity is essentially gone. Whilst there has been some interesting related wor= k from groups like MODRNA on solutions to combat this like 'Account Porting= ', they often assume the old provider remains online and willing to facilitate in the account porting process so= that the End-User can migrate to a new provider. SIOP actually elected to = do something different here by using cryptography, instead of the End-User = identifier being something like a GUID asserted within the domain of the provider, SIOP defined this inste= ad as a public key fingerprint associated to a private key that's assumed t= o be under the control of the user. In doing so the identity itself becomes= portable between providers by transferring the associated private key. Now this approach does have drawbacks and argu= ably encourages what many would refer to as bad cryptographic practise by n= ot allowing any way to do key rotation, however the idea was there. 

    &nb= sp;

    = How GNAP can solve for this? By having flexibility around how the resou= rce owner / End-User is referred to by the Authorization server (e.g allow = the identifier to be something like a public key or a resolvable identifier to public keys such as a DID)

    &nb= sp;

    I p= ersonally think that GNAP should be a flexible :carrier: of identifiers and= other bits of identity information. This is the main reason we went with t= he Subject Identifiers draft from SECEVENT: it=92s set up to talk about a variety of different kinds of iden= tifiers, all of them asserted in the context of the AS. If there=92s a defi= nition for a DID URL or a JWK in the sub_ids object structure, GNAP would b= e able to just use it directly alongside every other format. I haven=92t seen those proposed yet, but it would be e= asy to do and, in my mind, would be a better solution than the portable ide= ntifiers proposal that was recently brought up in the FAPI working group in= OIDF. (A side note, but the main problem I have here is that it=92s pasting semantics and formats onto a fi= eld where none existed before, and that=92s rife for problems. Better to ha= ve a structure that takes that into account from the start, in my view.)



    Solving the NASCAR problem - One of those enduring problems in ident= ity systems, which I think is really about the three way negotiation going = on between the RP, the End-User and the Provider. SIOP's solution pushed fo= r most of the power in this decision making process to lie with the End-User, letting them decide who they want= as their provider rather than RP's providing an enumeration of who they su= pport via provider icons on their login page and End-Users having to select= from those options. It accomplished this via using a custom URL scheme of `openid://` where the End-User would= register their chosen provider as a protocol handler for the `openid://` s= cheme. However, again as a solution it's not without it's challenges, notab= ly; only a single registration at a time can be supported, the actual identity of the provider remains blind= to the RP until after the request is sent and it requires registration or = some form of default handling (e.g when there is no provider registered).
    How GNAP can solve for this? I actually don't think this is core to = GNAP, there may be some considerations around discovery that are worth payi= ng attention to but not much in the core protocol design.

    &nb= sp;

    SIO= P doesn=92t really solve the NASCAR issue since SIOP, by design, becomes ye= t one more login option among many. I think GNAP can help this by enabling = user-directed provider discovery to kick off the process, but I agree that the core protocol doesn=92t really = have much to say here, and shouldn=92t.


    = Exploring different deployment models for the provider - This is the mo= st frequently talked about aspect of SIOP and perhaps the most interesting = to GNAP. I like to think about the scope of this issue as designing to allow for either a partially or fully = distributed/decentralized provider, rather than a centralized one (e.g an H= TTP based AuthZ server). As you noted this does come with its challeng= es many of which are technical in nature, i.e how to appropriately address a decentralized provider and what protoco= ls are used to communicate with the provider.

    How GNAP can solve for this? I think that's what much of the di= scussion on this thread will be about and whether there is a hybrid model w= here some responsibility is still centrally administered like token issuanc= e, while allowing other aspects to occur in a more distributed manner. Ideally though I'd like to see consideration= for a completely distributed model too.

    &nb= sp;

    I a= gree that this seems to be the most interesting place for overlap. I don=92= t actually think the =93hybrid=94 approach centralizes things. Instead, you= can think of the RS as having an associated AS, and that AS accepting user consent and claims at runtime from a variet= y of sources (wallets, VCs, etc.). In this way, we aren=92t talking about a= single AS in the world handling all of these requests, we=92re talking abo= ut a distributed network of AS=92s associated with an even more widely distributed set of RS=92s. SSI and its associated= technologies would help these =93local=94 AS=92s issue access tokens witho= ut the RO needing to have an account, or even necessarily directly interact= ing with the AS. There=92s currently a technology gap there, but my thoughts are that this is where the changes to the inter= action modes section can really come to play. 

    &nb= sp;

    I t= hink the notion of a non-HTTP AS is interesting, but I=92m not sure if that= =92s something GNAP ought to be solving for. I think that there=92s a deep = value in building on top of HTTP for the core protocol, and not abstracting away concepts from it. Otherwise, you e= nd up re-inventing layers, and you get something like SOAP all over again. = :)

    &nb= sp;

    &nb= sp;=97 Justin


    &nb= sp;

    Tha= nks,

    3D"Mattr=

     

    Tobias L= ooker

    Mattr

    +64 (0) 27 378 0461
    tobias.lo= oker@mattr.global

    =

    3D"Mattr<= /span>

    3D"Mattr

    3D"Mattr=


    This communication, including any at= tachments, is confidential. If you are not the intended recipient, you shou= ld not read it - please contact me immediately, destroy it, and do not copy= or use any part of this communication or disclose anything about it. Thank you. Please note that this communicat= ion does not designate an information system for the purposes of the Electr= onic Transactions Act 2002.

    &nb= sp;

    &nb= sp;

    On = Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:<= /p>

    Hi = Justin,

    &nb= sp;

    I a= gree that defining AS role primarily as a token issuer is a fruitful idea. = Solving this problem well would also respond to the challenges discussed pr= eviously on the list. 

    &nb= sp;

    Che= ers

    Fab= ien 

     

    Le = mer. 17 f=E9vr. 2021 =E0 23:27, Justin Richer <jricher@mit.edu> a =E9crit :

    The= last interim call had a lot of discussion on SSI technologies such as digi= tal wallets, and how those fit with GNAP. I think it=92s worth continuing t= hat conversation here on the list. There are a few issues in the tracker that give some background, too:

    &nb= sp;

    &nb= sp;

    The= re=92s been a lot of interesting work recently in the OpenID Foundation aro= und using the Self-issued OP (SIOP) functionality to bootstrap an SSI style= login. This makes extensive use of the implicit flow and front channel messaging, but minimization of the fro= nt channel for message passing is a key design tenet of GNAP (so much so th= at it=92s included in our charter). Instead, GNAP has been built around an = idea that everything starts the same way: with an HTTP request to the AS. 

    &nb= sp;

    The= idea of an on-device AS has been brought up a lot, and we need to consider= if and how we want to deal with these kinds of use cases. The most obvious= way to address these would be to do some kind of clever off-HTTP hack like SIOP, but keep in mind that even= SIOP generally starts off with an HTTP-based discovery call by the RP to m= ake things work.

    &nb= sp;

    My = personal stance is that to do this, we need to re-evaluate our assumptions = about exactly what an AS does and what it needs to do those things. In OAut= h 2, it=92s assumed that the AS is the device that=92s authenticating the user, collecting consent, managing the = client=92s registration, and creating an access token based on whatever set= of rights that are associated with all of those things. In UMA, this is tu= rned around a bit by letting the RO present a bunch of nebulous =93claims=94 interactively, but still at the A= S. 

    &nb= sp;

    Wit= h both of these, a key aspect remains: the AS needs to gather necessary inf= ormation, and issue the access token (or identifiers/assertions). Because o= f how the protocol works, the client software now has a better opportunity to present information to the AS, ei= ther directly in the request or by introducing the AS to another software c= omponent during the =93interaction=94 phase. So, what if we think of the AS= primarily as a =93token issuer=94? 

    &nb= sp;

    For= example, if the client can present a verifiable credential (VC) that repre= sents the end user, the AS can validate that VC and make an access token on= behalf of that user, without having the user log in or interact with the AS at all. This VC can contain whatev= er access rights the token needs to represent, and the AS can translate tha= t into an artifact that the downstream RS=92s can interpret, without having= to see the original VC or the user at all. The AS is still HTTP based, but all the essential security and rig= hts elements are provided by the wallet. In this way, we can expand on the = privacy-preserving aspects of OAuth and bridge the worlds of SSI and web AP= Is without violating the basic nature of either.

    &nb= sp;

    Com= ing from the OAuth world, it feels weird to issue tokens like this, but the= re=92s precedent for this kind of thing. Today, a there are a number of ser= vice-based OAuth AS's that are told what claims need to get put into the access token by some trusted componen= t. All of this happens outside the OAuth protocol. In GNAP, I think it make= s sense to account for this kind of thing in how we define the protocol. Th= at isn=92t to say all of these pieces need to be defined in the core, but the base protocol ought to be able to = handle being extended in this direction as needed.

    &nb= sp;

    I= =92m really interested to hear other people=92s thoughts on how this could = come together.

    &nb= sp;

    &nb= sp;=97 Justin

    -- =
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/= listinfo/txauth

    -- =
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/= listinfo/txauth


    This communication, including any attachments, is confidential. If=
 you are not the intended recipient, you should not read it - please contac=
t me immediately, destroy it, and do not copy or use any part of this commu=
nication or disclose anything about it. Thank you. Please note that this co=
mmunication does not designate an information system for the purposes of th=
e Electronic Transactions Act 2002.=

    &nb= sp;

    -- =
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/= listinfo/txauth

    -- =
    TXAuth mailing list
    TXAuth@ietf.org https://www.google.com/url?q= =3Dhttps://www.ietf.org/mailman/listinfo/txauth&source=3Dgmail-imap&= ;ust=3D1614379828000000&usg=3DAOvVaw3avsUGQ48fo1OUQV0vyyKd

    &nb= sp;


    &nb= sp;

    -- =
    TXAuth mailing list
    TXAuth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth

    &nb= sp;

    --_000_FR2P281MB01385E9064D7D5F70B09DEAA8D9E9FR2P281MB0138DEUP_-- From nobody Wed Feb 24 22:10:00 2021 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 84EA13A13B9 for ; Wed, 24 Feb 2021 22:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.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 sD9CSJPHh2pb for ; Wed, 24 Feb 2021 22:09:53 -0800 (PST) Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87213A13B7 for ; Wed, 24 Feb 2021 22:09:53 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by caesium6.alkaline.solutions (Postfix) with ESMTPA id 0384720473F; Thu, 25 Feb 2021 06:09:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1614233390; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DzNUP6pYhLSckq9XHyJoYtr3lIMsSG3teJDEJ2dM90E=; b=Fz3/nIDMDsg7AF7BEbMHYJBgWwsyo75r7HP83/inkNwqQsNm7K1pY5EvlKKq5XBtx4fegZ +pnjX/F4lhcDo3Y1NIaAtGk0Uq9kjZqyWKaixjjV53n/qaxiG/FjyQLUORwdj1C3kL+7ZQ npkfgCKFXIut2z31QKQNHEARaptPYs4= From: David Waite Message-Id: <8C143508-DEB0-412C-BB05-6855E097070F@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_061EB6BB-89C4-4D11-9FF6-5BBC4BAE5C77" Mime-Version: 1.0 Date: Wed, 24 Feb 2021 23:09:47 -0700 In-Reply-To: Cc: Justin Richer , Adrian Gropper , Denis , Francis Pouatcha , txauth gnap To: Francis Pouatcha References: <4EAA60A4-4800-400F-A70A-F7B7F1A6CB0A@mit.edu> <73cd4e8b-c843-ab87-c640-eea763b6002a@free.fr> <34DD2820-06F8-4226-A987-DF6F1105B87D@mit.edu> Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com X-Spamd-Bar: / Archived-At: Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 06:09:59 -0000 --Apple-Mail=_061EB6BB-89C4-4D11-9FF6-5BBC4BAE5C77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 24, 2021, at 6:14 PM, Francis Pouatcha = wrote: In an attempt to clarify (please correct me if I=E2=80=99m off): > A VC might be produced by an authority (let assume an AS) in a direct = negotiation between RO and AS. No involvement of the Client. I will = call this a direct interaction. 1. If I understand correctly, this is talking about the resource owner = as if it were participating as a client which can negotiate receiving a = verifiable credential as a type of non-delegated authorization token. = This should probably be a distinctly named role in this sort of protocol = like =E2=80=9Cholder=E2=80=9D or =E2=80=9Cwallet=E2=80=9D. I=E2=80=99ll = pick holder. > The VP is produced by the RO and presented to the Client. No = involvement of the AS. This is also a direct interaction. 2. So in this case the holder is presenting a token to the client, so = the holder is acting as a client and the =E2=80=9CClient=E2=80=9D is = acting as GNAP resource server. The token is manipulated by in some = manner and being given as a verifiable presentation which will act as = delegated authorization > The presentation of this original RO produced VP by a Client to an RS = might require a new presentation produced by the Client and warping the = original VP. I call this an embedded interaction. I am missing this one = in GNAP. 3. And now the =E2=80=9CClient=E2=80=9D, is acting as a client, trying = to get a piece of software (possibly an AS - possibly a _different_ AS = from #1) to translate the VP to a token format that the desired ultimate = RS will consume If I understand all of this correctly, the issue is that the verifiable = presentation given to the client needs to actually be a verifiable = credential issued by the holder to represent the delegation and to give = the client something they are able to present to others. I suspect this = is a cryptographic protocol issue and not a network protocol one, where = the VC/VP proof mechanism needs to allow for delegation. > The =E2=80=98Embedded=E2=80=99 suggestion did not make it pass the = initial discussion, because we were unable to justify it legitime use to = the OAuth legacy folks. We have been using this interaction mode in the = banking world for the last 20 years through diverse protocols. The problem is that the proof on a VP is not universally valid for all = presentation proofs. The proof may _only_ be verifiable by the client, = and not to an AS or RS that it is later echoed to.=20 > By adopting the embedded interaction, GNAP bridges the way to SSI. > =20 > Please to not talk about =E2=80=9Cembedding user password=E2=80=9D a = la =E2=80=9Cpassword grant=E2=80=9D. I am referring to allowing a client = carry a cryptogram produced by the RO to the RS. Indeed an AS is not needed for this - you just need delegatable = credentials :-) The AS is similar to what Microsoft used to refer to as a Security Token = Service (STS) - it is something that consumes tokens from parties it = trusts and emits tokens that other parties trust. =E2=80=9CToken=E2=80=9D = may be an abstract security check - a username/password form and consent = dialog might qualify as a =E2=80=9Ctoken=E2=80=9D that can be consumed. The AS serves as a concentration point of business logic concerns and = policy in many deployments - rather than have many RSes know how to do = things like verify the user=E2=80=99s authentication and capture = consent, a single AS does that. Likewise, the tokens which are emitted = could be in a complex format like JSON-LD and ZKP proofs - or could be = in a very optimized format where policy decisions have already been made = for the RSes. In the sense of an STS, it makes sense for the AS to issue a VC to a = holder has attributes representing system capabilities that the user is = allowed to delegate. It also makes sense for the STS to take a = presentation of a credential representing user granted capabilities to a = client, validate it, and translate that to a format that a RS might = prefer to consume like a JWT access token. > If we define the producer of the Token to be an AS, the we will have = to show a mortal how to run the http based A-(Server) on the user = device. There are lots of ways to get valid tokens other than OAuth, OpenID = Connect, and GNAP. But per the STS description above, is is unlikely an = RS would choose to trust an AS hosted on a user=E2=80=99s device. > Even if we narrow the definition of the AS to producing the VC and = not the VP, we still have a problem, as some VC might be produced by the = user. I don=E2=80=99t quite understand this - what purpose would the AS have = to produce VPs in these scenarios. I would assume a VP from the AS would = be asserting the AS as the subject, not a subject of any of the other = roles. =20 > In the EU we will be witnessing eIDAS certificates issued to user, = allowing them to produce their own VC, without the help of server based = AS? Shall this make those VC producing applications running on the user = device AS? Then we will have to redefine AS. I would assume these are delegatable credentials. However, I would expect that many parties would not want to make a trust = decision based on that credential (was the user really allowed to = delegate this responsibility to another party? Have I authenticated this = party? Can I track this party if they are abusing the system? How do I = know if the capabilities that the user has delegated are even = capabilities the user is authorized to?=E2=80=A6 and do I really have to = do all of this evaluation on every single network request?) . An AS = could request a presentation, evaluate all of that policy, and issue a = token that a RS would consume. -DW= --Apple-Mail=_061EB6BB-89C4-4D11-9FF6-5BBC4BAE5C77 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

    On Feb 24, 2021, at 6:14 PM, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> = wrote:

    In an attempt to = clarify (please correct me if I=E2=80=99m off):

    A VC might = be produced by an authority (let assume an AS) in a direct negotiation = between RO and AS. No involvement of the Client.  I will call this = a direct interaction.

    1. If I understand correctly, this is talking = about the resource owner as if it were participating as a client which = can negotiate receiving a verifiable credential as a type of = non-delegated authorization token. This should probably be a distinctly = named role in this sort of protocol like =E2=80=9Cholder=E2=80=9D or = =E2=80=9Cwallet=E2=80=9D. I=E2=80=99ll pick holder.

    The VP is produced by the RO and = presented to the Client. No involvement of the AS. This is also a direct = interaction.

    2. = So in this case the holder is presenting a token to the client, so the = holder is acting as a client and the =E2=80=9CClient=E2=80=9D is acting = as GNAP resource server. The token is manipulated by  in some = manner and being given as a verifiable presentation which will act as = delegated authorization

    The presentation of this original = RO produced VP by a Client to an RS might require a new presentation = produced by the Client and warping the  original VP. I call this = an embedded = interaction. I am = missing this one in GNAP.

    3. And now the =E2=80=9CClient=E2=80=9D, is acting = as a client, trying to get a piece of software (possibly an AS - = possibly a _different_ AS from #1) to translate the VP to a token format = that the desired ultimate RS will consume

    If I understand all of this correctly, the issue = is that the verifiable presentation given to the client needs to = actually be a verifiable credential issued by the holder to represent = the delegation and to give the client something they are able to present = to others. I suspect this is a cryptographic protocol issue and not a = network protocol one, where the VC/VP proof mechanism needs to allow for = delegation.

    The =E2=80=98Embedded=E2=80=99 suggestion did not make it pass the = initial discussion, because we were unable to justify it legitime use to = the OAuth legacy folks. We have been using this interaction mode in the = banking world for the last 20 years through diverse = protocols.

    The = problem is that the proof on a VP is not universally valid for all = presentation proofs. The proof may _only_ be verifiable by the client, = and not to an AS or RS that it is later echoed to. 

    By adopting the embedded = interaction, GNAP bridges the way to SSI.
     
    Please to = not talk about =E2=80=9Cembedding user password=E2=80=9D= a la =E2=80=9Cpassword grant=E2=80=9D. I am referring = to allowing a client carry a cryptogram produced by the RO to the = RS.

    Indeed an AS = is not needed for this - you just need delegatable credentials = :-)

    The AS is similar to what = Microsoft used to refer to as a Security Token Service (STS) - it is = something that consumes tokens from parties it trusts and emits tokens = that other parties trust. =E2=80=9CToken=E2=80=9D may be an abstract = security check - a username/password form and consent dialog might = qualify as a =E2=80=9Ctoken=E2=80=9D that can be consumed.

    The AS serves as a concentration point of business = logic concerns and policy in many deployments - rather than have many = RSes know how to do things like verify the user=E2=80=99s authentication = and capture consent, a single AS does that. Likewise, the tokens which = are emitted could be in a complex format like JSON-LD and ZKP proofs - = or could be in a very optimized format where policy decisions have = already been made for the RSes.

    In = the sense of an STS, it makes sense for the AS to issue a VC to a holder = has attributes representing system capabilities that the user is allowed = to delegate. It also makes sense for the STS to take a presentation of a = credential representing user granted capabilities to a client, validate = it, and translate that to a format that a RS might prefer to consume = like a JWT access token.

    If we define = the producer of the Token to be an AS, the we will have to show a mortal = how to run the http based A-(Server) on the user = device.

    There are = lots of ways to get valid tokens other than OAuth, OpenID Connect, and = GNAP. But per the STS description above, is is unlikely an RS would = choose to trust an AS hosted on a user=E2=80=99s device.

     Even if we narrow the definition = of the AS to producing the VC and not the VP, we still have a problem, = as some VC might be produced by the = user.

    I = don=E2=80=99t quite understand this - what purpose would the AS have to = produce VPs in these scenarios. I would assume a VP from the AS would be = asserting the AS as the subject, not a subject of any of the other = roles.
     
    In the EU we will be witnessing eIDAS = certificates issued to user, allowing them to produce their own VC, = without the help of server based AS? Shall this make those VC producing = applications running on the user device AS? Then we will have to = redefine AS.

    I would = assume these are delegatable credentials.

    However, I would expect that many parties would = not want to make a trust decision based on that credential (was the user = really allowed to delegate this responsibility to another party? Have I = authenticated this party? Can I track this party if they are abusing the = system? How do I know if the capabilities that the user has delegated = are even capabilities the user is authorized to?=E2=80=A6 and do I = really have to do all of this evaluation on every single network = request?) . An AS could request a presentation, evaluate all of that = policy, and issue a token that a RS would consume.

    -DW
    = --Apple-Mail=_061EB6BB-89C4-4D11-9FF6-5BBC4BAE5C77-- From nobody Sat Feb 27 23:46:11 2021 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 45E7E3A0C20 for ; Sat, 27 Feb 2021 23:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=mnot.net header.b=XakR1jY1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BX2qlru/ 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 gfE0F2uVEXxO for ; Sat, 27 Feb 2021 23:46:06 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C2D3A0C1E for ; Sat, 27 Feb 2021 23:46:06 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A6D2C5C0077 for ; Sun, 28 Feb 2021 02:37:45 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 28 Feb 2021 02:37:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=BtwfGXs6EOVKSPs5gzHyyzJUoDQziKVkGf5rKcAWKww=; b=XakR1jY1 80WlxfohWFKJVCfW0aY02vCxMX07xO9r3M467igJh9KAE8mQ8nkOgjaeZ2VHufSo w7HBnH4WrYHc8FrljJEpa4rmeHwF3aeMH67KH/ikEFA2t3GTTGgErpbkO6oJo0tt lw2NsRmiv2suO6R4qZUuTsktlm+ITwHdUlxCbj4K2Dzw93gaABDL7qCXsIB3/goc Gz/zS8cABmfjDrNFN1oMt8LfzOn89cAIBk4OgFf7MEYuMWAlfWTapJ8xcNe6p+M0 iou2KLe05YzBPNK3sdAZAOV8xCLD4yT5ZjaUv5Rmt0QwwDp0pK2zg+vJk5booIEw WZ1BE7hTqyO9xQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=BtwfGXs6EOVKSPs5gzHyyzJUoDQzi KVkGf5rKcAWKww=; b=BX2qlru/gY9ghRuxr3GTp0OIjwk5PflTeHURyOde5ykqS +lXuPq7yifydRIpA8XxllyZcfO7etBWUDsRW1twkUg7XauXqQ70cCAjXgpMnYpEw vO3T/9FpCBGQBEHxCi9C8whrQILot41aHXfuXA4ho+Be3NSI/VVZuOy9WThyhmOg OU8jXXGHy2KyDSp6AZHmeirsuWLBjRN/Fxt8oynClSmv8kIK5H/vxCb69iXvjF3E F7IJ1OLNuHG7+SL6h/z5MmlOFtZSxd+hVtzWvHDwkToHSinPZdROv8yL+4TEAiyo kNJwXIirL7RlO46L/LWI1SiBhjqfdFret7DFKjwUQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrleehgddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtthgvrh hnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudeiteen ucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrjedtrddvtdejrdduie ehnecuvehluhhsthgvrhfuihiivgepfeenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az184-358.internal.cloudapp.net (unknown [40.70.207.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 7C316240057 for ; Sun, 28 Feb 2021 02:37:45 -0500 (EST) Content-Type: multipart/alternative; boundary="===============8056351747884629915==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20210228073745.7C316240057@mailuser.nyi.internal> Date: Sun, 28 Feb 2021 02:37:45 -0500 (EST) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2021 07:46:08 -0000 --===============8056351747884629915== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-gnap/core-protocol (+1/-2/=F0=9F=92=AC14) 1 issues created: - Include body hash in Detached JWS (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/201=20 4 issues received 14 new comments: - #201 Include body hash in Detached JWS (10 by aaronpk, adeinega, jriche= r) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/201=20 - #196 Proving Possession of a Key for the AS and RS (2 by adeinega, jric= her) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/196=20 - #180 grant_request_endpoint, HTTPS and fragment component (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/180=20 - #122 Group interaction mode flags (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/122=20 2 issues closed: - grant_request_endpoint, HTTPS and fragment component https://github.com= /ietf-wg-gnap/gnap-core-protocol/issues/180=20 - Group interaction mode flags https://github.com/ietf-wg-gnap/gnap-core-= protocol/issues/122=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+2/-2/=F0=9F=92=AC4) 2 pull requests submitted: - Syntax and schema based normalization for URI in the htu claim. (by ade= inega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/202=20 - fix token example (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/200=20 4 pull requests received 4 new comments: - #202 Syntax and schema based normalization for URI in the htu claim. (1= by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/202=20 - #200 fix token example (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/200 [Editorial]= =20 - #199 Adding information about the Cache-Control header and its value. (= 1 by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/199=20 - #194 Suggested changes for Discovery field names (1 by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/194=20 2 pull requests merged: - Requirements for the location of grant_request_endpoint. https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/183 [Pending Me= rge]=20 - grouping interaction modes https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/164 [Pending Me= rge]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============8056351747884629915== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (GNAP Weekly GitHub Activity Summary)

    Sunday February 28, 2021

    Events without label "editorial"

    Issues

    ietf-wg-gnap/core-protocol (+1/-2/=F0=9F=92=AC14)

    1 issues created:

    4 issues received 14 new comments:

    2 issues closed:

    Pull requests

    ietf-wg-gnap/core-protocol (+2/-2/=F0=9F=92=AC4)

    2 pull requests submitted:

    4 pull requests received 4 new comments:

    2 pull requests merged:

    Repositories tracked by this digest:

    --===============8056351747884629915==--