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

[Tom Jones <[e-mail]>]

that would certainly work. But my use case of interest is healthcare, and I
cannot imagine forcing users to pay to get an identifier for health care.
The other major problem is the 80% of the world's population that lives in
what you and I consider to be poverty.
Peace ..tom


On Wed, Nov 18, 2020 at 10:13 PM Fabien Imbault <[e-mail]>
wrote:

> Hi Tom,
>
> My answer is completely speculative.
> But I guess it would probably involve the end-user paying to some sort of
> service provider (just like one pays for having a VPN). With the same
> potential risks (i.e free tiers that serve ads or resell your data, or
> limit volumes of connections)?
>
> Cheers
> Fabien
>
>
> Le jeu. 19 nov. 2020 à 06:23, Tom Jones <[e-mail]> a
> écrit :
>
>> Actually that's not the hard problem, which is, once the user wanders off
>> on some path that is not anchored in the browser, how does the path get
>> back to the same place in the browser?
>> This is "straightforward" when the path from siop to some url in the
>> cloud is completely separated from the path between the user and the
>> client, but that is not the path usually taken.
>> We need some new entity to pull this off. Call it the AS proxy if you
>> will. The problem I have with that is who is going to pay the AS proxy?
>> If I can figure that payment issue out, I think I can complete the rest
>> of the flows.
>>
>> 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
>>>
>>