[Openid-specs-ab] SIOP Scope proposal

Thu Dec 3 01:33:38 UTC 2020

I do not believe it was considered for OIDC.
I do believe that FAPI addresses app-app comms, but AFAIK it was not with
on-phones comms.  In any case that was addressed by the UKOBIE specs not
the OIDF specs.
Note that i am not addressing the capture of URLs by apps which is probably
out-of-scope of OIDF in any case. In general apps only know URLs and not
locations unless loop-back is explicitly requested. That is why I asked if
you intended to support loop-back. While that might conceivably be
in-scope, it is very difficult to pull off.
Peace ..tom

On Wed, Dec 2, 2020 at 5:08 PM Tobias Looker <tobias.looker at mattr.global>
wrote:

> Tom,
>
> Sorry to clarify you are saying that point 3 was not in scope for the
> original SIOP chapter or that it should not be in scope for revision?
>
> Thanks,
> [image: Mattr website] <https://mattr.global>
> *Tobias Looker*
> Mattr
> +64 (0) 27 378 0461
> tobias.looker at mattr.global
> [image: Mattr website] <https://mattr.global> [image: Mattr on LinkedIn]
> <https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]
> <https://twitter.com/mattrglobal> [image: Mattr on Github]
> <https://github.com/mattrglobal>
> 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, Dec 3, 2020 at 2:03 PM Tom Jones <thomasclinganjones at gmail.com>
> wrote:
>
>> OK, I don't believe that is a problem that this group should address.
>> Peace ..tom
>>
>>
>> On Wed, Dec 2, 2020 at 4:53 PM Tobias Looker <tobias.looker at mattr.global>
>> wrote:
>>
>>> Tom,
>>>
>>> Sorry my proposal is not aiming to talk solutions, rather just correctly
>>> *classify* the different problems that the SIOP chapter/work is aiming
>>> to solve, to support more productive conversations about the potential
>>> solutions.
>>>
>>> Thanks,
>>> [image: Mattr website] <https://mattr.global>
>>> *Tobias Looker*
>>> Mattr
>>> +64 (0) 27 378 0461
>>> tobias.looker at mattr.global
>>> [image: Mattr website] <https://mattr.global> [image: Mattr on LinkedIn]
>>> <https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]
>>> <https://twitter.com/mattrglobal> [image: Mattr on Github]
>>> <https://github.com/mattrglobal>
>>> 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, Dec 3, 2020 at 1:47 PM Tom Jones <thomasclinganjones at gmail.com>
>>> wrote:
>>>
>>>> Let me get this straight.
>>>> 1) THe user installs a wallet app to act as a SIOP (native, pwa,
>>>> whatever)
>>>> 2) The user navigates to the RP and the RP installs a PWA on the user
>>>> device.
>>>> 3) The wallet communicates with the RP PWA.  How exactly? by loop-back
>>>> - that doesn't work so well.
>>>> or am i missing something.
>>>> Peace ..tom
>>>>
>>>>
>>>> On Wed, Dec 2, 2020 at 4:42 PM Tobias Looker <tobias.looker at mattr.global>
>>>> wrote:
>>>>
>>>>> Hi Tom,
>>>>>
>>>>> In conventional OpenID Connect (the model that is most widely used and
>>>>> deployed today), its assumed that the OpenID Provider is an HTTP based
>>>>> Authorization server (due the foundation of OAuth2.0). The self issued
>>>>> chapter however contemplates the question, what if the provider is instead
>>>>> an application running on the end users device such as a native app or PWA?
>>>>> This point is designed to address the issues associated with doing just
>>>>> that.
>>>>>
>>>>> Thanks,
>>>>> [image: Mattr website] <https://mattr.global>
>>>>> *Tobias Looker*
>>>>> Mattr
>>>>> +64 (0) 27 378 0461
>>>>> tobias.looker at mattr.global
>>>>> [image: Mattr website] <https://mattr.global> [image: Mattr on
>>>>> LinkedIn] <https://www.linkedin.com/company/mattrglobal> [image:
>>>>> Mattr on Twitter] <https://twitter.com/mattrglobal> [image: Mattr on
>>>>> Github] <https://github.com/mattrglobal>
>>>>> 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, Dec 3, 2020 at 1:35 PM Tom Jones via Openid-specs-ab <
>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>
>>>>>> not sure i understand the point of 3 - RP-OP colocation - pls provide
>>>>>> a use case
>>>>>> Peace ..tom
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 2, 2020 at 4:00 PM Tobias Looker via Openid-specs-ab <
>>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Over the past while, there has been a lot of interest and work going
>>>>>>> into a revision to chapter 7 of the OpenID Connect Core chapter (Self
>>>>>>> Issued Provider). It is my impression that because this chapter originally
>>>>>>> aimed to solve several quite large problems, we would benefit from
>>>>>>> classifying these better to ensure we can have the most productive
>>>>>>> conversations possible. My proposal, that I have already informally raised
>>>>>>> on the Pacific AB WG call, is to break apart the scope of SIOP into 5
>>>>>>> separate problems.
>>>>>>>
>>>>>>> 1. Enabling portable subject identifiers between providers - Define
>>>>>>> how to use techniques such as asymmetric cryptography and higher level
>>>>>>> technologies like Decentralized Identifiers to create subject identifiers
>>>>>>> that are not intrinsically bound to a particular OP and hence can be ported
>>>>>>> between providers.
>>>>>>> 2. Solving for provider discovery and registration - Evaluating
>>>>>>> solutions to problems like the nascar problem, how does an RP come to have
>>>>>>> a relationship with an OP or understand its capabilities along with what
>>>>>>> role the user plays in this selection/discovery process.
>>>>>>> 3. RP - OP co-location on the same device - Dealing with the unique
>>>>>>> requirements that are brought about when the OP the RP is communicating
>>>>>>> with is on the same device (e.g in the form of a PWA or Native App), rather
>>>>>>> than a traditional Authorization server.
>>>>>>> 4. Credential Issuance support - Issuing credentials from OpenID
>>>>>>> Connect flows.
>>>>>>> 5. Credential Presentation support - Presenting credentials in
>>>>>>> OpenID Connect flows.
>>>>>>>
>>>>>>> Its important to note that in my opinion only problems 1,2 and 3
>>>>>>> were in the original scope of the SIOP chapter however due to the continued
>>>>>>> evolution of the SSI/Decentralized Identity and Verifiable Credential
>>>>>>> space, many uses cases that SIOP has come to be associated with involve
>>>>>>> verifiable credentials and there for problems 4. and 5. should be addressed.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> [image: Mattr website] <https://mattr.global>
>>>>>>> *Tobias Looker*
>>>>>>> Mattr
>>>>>>> +64 (0) 27 378 0461
>>>>>>> tobias.looker at mattr.global
>>>>>>> [image: Mattr website] <https://mattr.global> [image: Mattr on
>>>>>>> LinkedIn] <https://www.linkedin.com/company/mattrglobal> [image:
>>>>>>> Mattr on Twitter] <https://twitter.com/mattrglobal> [image: Mattr
>>>>>>> on Github] <https://github.com/mattrglobal>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Openid-specs-ab mailing list
>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Openid-specs-ab mailing list
>>>>>> Openid-specs-ab at lists.openid.net
>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>> 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.
>>>
>>>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20201202/1b0b24c8/attachment.html>