[Openid-specs-ab] Is authorize endpoint required in 'SSO for Mobile'? was: [External Sender] Re: Spec Call Notes 18-Nov-24

Wed Nov 27 19:52:27 UTC 2024

Why can't a different grant type produce new access and/or refresh tokens (at the same time)?

-Brock

On 11/27/2024 11:44:08 AM, George Fletcher <george.fletcher at capitalone.com> wrote:
So my main concern with using a specialized grant type is that generally the mobile app wants to obtain the device_secret at the same time it is obtaining access and refresh tokens. I think using a specialized grant time would mean that the mobile app would need to make two calls. 

I'm open to suggestions :)

On Wed, Nov 27, 2024 at 10:49 AM Brock Allen <brockallen at gmail.com [mailto:brockallen at gmail.com]> wrote:

Great, thanks!

Another thought (hijacking my own thread), we were looking at the grant type and were wondering if a more specialized grant type made more sense (rather than the more general token-exchange). Any concerns for confusion in other token exchange workflows? Any thoughts into that?

Thanks again.

-Brock

On 11/27/2024 10:09:01 AM, George Fletcher <george.fletcher at capitalone.com [mailto:george.fletcher at capitalone.com]> wrote:
Hi Brock,

Generally, yes. It should be possible to use the OAuth 2.0 for First Party Apps to obtain the device secret by specifying the "device_sso" scope which identifies that a device_secret should be returned from the token endpoint.

Of course, the OAuth 2.0 for First-Party Applications wasn't even an idea when this spec was started. That said, given the spec is just at the implementers draft stage, updating it to current times makes sense... though it will likely introduce breaking changes for those who have already implemented the spec. That might not matter too much if the implementations are local to a first party environment.

Thanks,
George

On Wed, Nov 27, 2024 at 9:12 AM Brock Allen <brockallen at gmail.com [mailto:brockallen at gmail.com]> wrote:

Thanks George. 

I'd also like to see some clarification in this document if the authorize endpoint is required to be used. 

What I mean is that what seems most important in this spec is the results from the token endpoint, and there are different ways a client might get results from the token endpoint (and not just by using the authorize endpoint). For example, the up and coming "OAuth 2.0 for First Party Clients" defines a way for a client to obtains results from the token endpoint. Could that flow (without using the authorize endpoint) then get a "device_secret", and then use that in another client app or on a different device to login via "OpenID Connect Native SSO for Mobile Apps"?

Thanks.

-Brock

On 11/27/2024 8:55:44 AM, George Fletcher via Openid-specs-ab <openid-specs-ab at lists.openid.net [mailto:openid-specs-ab at lists.openid.net]> wrote:
So I'd like to open the topic of updating the spec to not require the id_token or at least drastically reduce the dependence on the id_token in the flows.

I'm very happy to work on those changes and produce an updated draft. I know some feel we don't need the spec at all but for those who've implemented it, or are interested in the work, is this a good path to pursue?

Thanks,
George

On Tue, Nov 19, 2024 at 3:17 PM Vladimir Dzhuvinov / Connect2id via Openid-specs-ab <openid-specs-ab at lists.openid.net [mailto:openid-specs-ab at lists.openid.net]> wrote:

When we implemented Native SSO we found the ID token to be redundant in the token exchange step.
The device_secret "token" can be made to include everything that the ID token has, plus more if necessary. Thus the device_secret was entirely sufficient to determine the SSO subject and what other properties were necessary for the native session, such as the device session expiration and the ACR of the original user authentication.
I tend to agree that sometimes customers can't be demanding enough with specs that bring cool new features. And just the opposite when the spec does nothing significant, other than going to markedly improve their security, long term. I just said to myself, I some of them are reading this.
I think the self-help strategy to stay sane at this job - and that includes on the customer front - is to produce specs that are consistently & conceptually simple, easy to implement and fit the landscape of surrounding specs. This is what feels bad and demoralises - having to implement specs that conflict with one another or break previous guidance. Then the acrobatics to explain and justify that to customers.

Vladimir Dzhuvinov
On 19/11/2024 19:19, Brian Campbell via Openid-specs-ab wrote:

Finding things in the archives is not easy (for me anyway) but here's one historical account of my prior push-back on progressing Native SSO https://lists.openid.net/pipermail/openid-specs-ab/2022-September/009376.html [https://urldefense.com/v3/__https://lists.openid.net/pipermail/openid-specs-ab/2022-September/009376.html__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIwOP8F1E$]

On Mon, Nov 18, 2024 at 5:53 PM Michael Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net [mailto:openid-specs-ab at lists.openid.net]> wrote:

Spec Call Notes 18-Nov-24

George Fletcher
Nat Sakimura
Mike Jones
Brian Campbell
David Waite
Tom Jones
Aaron Parecki

Native SSO spec
                https://bitbucket.org/openid/connect/pull-requests/742 [https://urldefense.com/v3/__https://bitbucket.org/openid/connect/pull-requests/742__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIQtja1Hk$]
                                Mike will review and merge if it looks OK
                There are 8 open issues for Native SSO - 3 to be closed by the PR above
                Brian questioned whether we should be taking this to final or not
                                Given that it may not be the best practice for doing this
                                He said that we could make it a blog post
                George asked if there is another best practice that we should document instead
                                He observed that no one has proposed a better way
                Mike said that Okta has implemented, so we should involve them
                                Yahoo has implemented it, Vladimir has implemented it
                George said that there's value in documenting these things
                                He wanted the working group to weigh in to improve it, which they have
                Mike observed that we're also doing first-party app work in the OAuth WG
                (Aaron joined the call at this point)
                Mike asked about Okta implementing the Native SSO spec
                                George said that Okta had extended it for a cross-device case in a prototype
                                Aaron said that it's available as an API
                                  https://developer.okta.com/docs/guides/configure-native-sso/main/ [https://urldefense.com/v3/__https://developer.okta.com/docs/guides/configure-native-sso/main/__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIKkdTIj8$]
                Aaron said that Google has deployed a similar thing
                                George said that he wrote this down so others could understand how to achieve what Google has
                Brian really dislikes the use of ID Tokens as hints and with different validation rules
                Brian said that that a sometimes problem with publishing specs is customers will see it and ask for it to be implemented
                                We should be cognizant of that

Mobile work
                George mused about whether we want to do any additional mobile-related work
                Mike asked what the MODRNA WG is doing now
                                People on the call didn't know

Bitbucket Issues
             https://bitbucket.org/openid/connect/issues?status=new&status=open&status=submitted&is_spam=!spam [https://urldefense.com/v3/__https://bitbucket.org/openid/connect/issues?status=new&status=open&status=submitted&is_spam=!spam__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIl9tvU48$]
                No new issues

Working Group GitHub Repositories
                We now have four working group GitHub repositories:
                1. https://github.com/openid/federation [https://urldefense.com/v3/__https://github.com/openid/federation__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kICqMvs5A$]
                2. https://github.com/openid/federation-extended-listing [https://urldefense.com/v3/__https://github.com/openid/federation-extended-listing__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kI5gKr-Ao$]
                                No issues or PRs
                                Implementations requested
                3. https://github.com/openid/federation-wallet/ [https://urldefense.com/v3/__https://github.com/openid/federation-wallet/__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIpxyRY3A$]
                                14 open issues
                                                Many of the early ones record things that were in pre-adopted versions of the spec
                                https://github.com/openid/federation-wallet/issues/39 [https://urldefense.com/v3/__https://github.com/openid/federation-wallet/issues/39__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kITErbkb8$] Authorized Credential within OpenID4VP metadata using Duckle
                                                Mike will review
                                https://github.com/openid/federation-wallet/issues/40 [https://urldefense.com/v3/__https://github.com/openid/federation-wallet/issues/40__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIv4NA8x8$] Trust Marks examples
                                                The examples seem reasonable
                                https://github.com/openid/federation-wallet/issues/41 [https://urldefense.com/v3/__https://github.com/openid/federation-wallet/issues/41__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIrMFRf9I$] Complex Trust Marks examples
                                                What's the motivation for these examples?
                                https://github.com/openid/federation-wallet/issues/42 [https://urldefense.com/v3/__https://github.com/openid/federation-wallet/issues/42__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIjUMqFGc$] Trust Mark with Intended Usage
                                                ditto
                4. https://github.com/openid/rp-metadata-choices [https://urldefense.com/v3/__https://github.com/openid/rp-metadata-choices__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIGYgdnsI$]
                                No issues or PRs
                                Mike knows of work to do due to the discussion on the list after the spec was contributed

                Nat pointed out that we need to update the repository page for the WG to list all the repositories
                                Mike agreed to take the action to do that

OpenID4VP
                It's currently in the 45-day foundation-wide review as a proposed Implementer's Draft
                Tom asked about user consent with credential presentation
                Mike suggested that if he has objections to the spec that he put them in issues
                                Then the objections are actionable
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net [mailto:Openid-specs-ab at lists.openid.net]
https://lists.openid.net/mailman/listinfo/openid-specs-ab [https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kI7qkZS8I$]

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

_______________________________________________ Openid-specs-ab mailing list Openid-specs-ab at lists.openid.net [mailto:Openid-specs-ab at lists.openid.net] https://lists.openid.net/mailman/listinfo/openid-specs-ab [https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kI7qkZS8I$]
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net [mailto:Openid-specs-ab at lists.openid.net]
https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kI7qkZS8I$ [https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kI7qkZS8I$]

The information contained in this e-mail may be confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.

_______________________________________________ Openid-specs-ab mailing list Openid-specs-ab at lists.openid.net [mailto:Openid-specs-ab at lists.openid.net] https://lists.openid.net/mailman/listinfo/openid-specs-ab [https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!IJnIG1GjnKHJiM091BcgJprXGmZvm_ww4crA1mAEJwhVHFVn0cooV-VSkzeLqXxyqDe5FHE-9ChqHJVgiu6aPEUBYXU$]

The information contained in this e-mail may be confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20241127/fe230b18/attachment-0001.htm>