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

[Dick Hardt <[e-mail]>]

It would seem that the mobile OSes would need to support a new scheme
"openid:" ... and provide a mechanism in both the mobile browser and mobile
apps to detect if an "openid:" handler has been installed.
ᐧ

On Tue, Nov 17, 2020 at 10:32 AM Tom Jones <[e-mail]>
wrote:

> yes - this is the sticking point for siop - not sure how it will get
> resolved.
> Peace ..tom
>
>
> On Tue, Nov 17, 2020 at 10:29 AM Dick Hardt <[e-mail]> wrote:
>
>> 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
>>>>>
>>>>