Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00

[Fabien Imbault <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> 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 <[e-mail]>
>> 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 à 13:06, Francis Pouatcha <[e-mail]> a
>>> écrit :
>>>
>>>> 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 <[e-mail]>
>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM
>>>> *To:* Francis Pouatcha <[e-mail]>
>>>> *Cc:* [e-mail] <[e-mail]>; Dick Hardt <
>>>> [e-mail]>; Tom Jones <[e-mail]>; Denis
>>>> <[e-mail]>; Justin Richer <[e-mail]>
>>>> *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 <[e-mail]>
>>>> 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 <[e-mail]> on behalf of Dick Hardt <
>>>> [e-mail]>
>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM
>>>> *To:* Tom Jones <[e-mail]>
>>>> *Cc:* Fabien Imbault <[e-mail]>; Denis <
>>>> [e-mail]>; GNAP Mailing List <[e-mail]>; Justin
>>>> Richer <[e-mail]>
>>>> *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_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app
>>>>
>>>>
>>>> ᐧ
>>>>
>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <
>>>> [e-mail]> 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 <[e-mail]>
>>>> 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
>>>> ᐧ
>>>>
>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <[e-mail]>
>>>> 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
>>>> <https://urldefense.us/v2/url?u=https-3A__youtu.be_Tq4hw7X5SW0&d=DwMFaQ&c=2plI3hXH8ww3j2g8pV19QHIf4SmK_I-Eol_p9P0CttE&r=D5lnfoa2MVZWELqVbbz71ooelbP7rVGCjGDSBNvUpYQ&m=ixsudGSr_dhG-SLiatb4Sz9FWslmywnYyZAOLgZxhl8&s=jdLLy0G1JTQCAOBZ6PeUgI0kiCtVJXrru0VToYWlNZ8&e=>
>>>> Peace ..tom
>>>>
>>>>
>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <[e-mail]> wrote:
>>>>
>>>> Ultimately, in most situations like these in the real world, the hurdle
>>>> isn’t 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’s coming from the AS. The same is true for an RS trusting
>>>> tokens from the AS. The hard question is less “how” to do that (which SSI
>>>> answers), but more “why” to do that (which SSI doesn’t answer very well,
>>>> because it’s a hard question).
>>>>
>>>> Still: it’s definitely a question about how to support this “AS on
>>>> device” element. We’ve 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’t 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’t 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’t fly. That said, we’ve
>>>> got an opportunity to more explicitly open up alternative communication
>>>> channels here, and that’s something I’d like to see engineered, even if
>>>> it’s an extension. I’d love to see a concrete proposal as to how that would
>>>> work over specific protocols, starting with what we’ve got today.
>>>>
>>>>  — Justin
>>>>
>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault <[e-mail]>
>>>> 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 <[e-mail]> 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
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>> --
>>>> TXAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>>
>>>> --
>>>> TXAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>> --
>>>> TXAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>>