[Openid-specs-ab] [External Sender] Re: Spec Call Notes 18-Nov-24
Vladimir Dzhuvinov / Connect2id
vladimir at connect2id.com
Wed Nov 27 22:04:04 UTC 2024
Thanks George.
The credential that does the magic of Native SSO is the device_secret.
It's an opaque token, so the OP is free to include the user identity and
all sorts of device session related info in it, making the ID token
redundant.
If we remove the ID token from the token exchange grant:
* The flow for client apps and the IdP is simplified
* The client apps only need to store the device_secret on the key
chain. An ID token is no longer shared between them.
* We save the IdP the following:
* Validating the ID token with an "exp" and "aud" exception
* Checking the ID token "ds_hash" against the device_secret
* Decrypting the ID token "sub" (for pairwise IDs)
* Checking the ID token "sub" against the device_secret subject
* Additionally, when the device_secret is updated, this obliging
the IdP to issue a matching ID token for it
* Use of the ID token as an authorisation can be considered an
anti-pattern
* The ID token may include personal details. When used at the token
endpoint, because it's usually a signed JWT and not an opaque
credential, these details may end up in the server logs.
Vladimir Dzhuvinov
On 27/11/2024 15:55, George Fletcher 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> 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> 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
>> 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
>> 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
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20241128/9fb2eceb/attachment-0001.htm>
More information about the Openid-specs-ab
mailing list