[Openid-specs-ab] [External Sender] Two questions on Native SSO draft

[Vladimir Dzhuvinov]

Hi George,

It would be really helpful to have the clarification in pt 2 in the 
spec. I have received questions of the "how does this native SSO compare 
to web SSO" kind on multiple occasions in the past. This will aid 
adoption because people will now have a clear picture in their mind 
where the security properties of native SSO stand in relation to web 
based SSO (which by now should be well known and understood).

Vladimir

On 08/02/2024 17:20, George Fletcher via Openid-specs-ab wrote:
> Comments inline...
>
> On Wed, Feb 7, 2024 at 8:19 PM Nat Sakimura via Openid-specs-ab 
> <openid-specs-ab at lists.openid.net> wrote:
>
>     Hi
>
>     (Mainly to George)
>
>     While reading the Native SSO draft, I stumbled on the following
>     questions. If you could clarify them, it would be helpful.
>
>     1) Device secret seems to be a token that is returned from the
>     token endpoint. Would it not be more appropriate to be called
>     device_token or something?
>
> The name device_secret came from an IIW session where I asked about 
> naming. Yes it is a token, issued by the authorization server and it 
> is intended to be "secret" between that device instance and the 
> Authorization server. I'm not sure changing the name at this time 
> would be good given the number of deployed implementations.
>
>     2) Is there any provision that assures the user of Native App 1
>     and Native App 2 is the same?
>
> Within the specification, there isn't any check. If we think about SSO 
> from a web perspective, there would not likely be a check of user 
> identity during the SSO flow. We consider use of the same device 
> instance as sufficient proof that the user is the same. If Native App 
> 2 requires an "identity proof" it could do it's own say faceID 
> challenge before engaging the Native SSO spec. So I think this is 
> possible outside of the current spec.
>
> I could probably add something to the security considerations section 
> if you think that would be useful.
>
>
>     Best,
>
>     Nat Sakimura
>     _______________________________________________
>     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!NK0VUtu5l6sa4r_L_46MditkoJboMNG7GdqxZBx38cDr9oPcoD1kpoWS9CWB5e6t7PqVgTNiyxGi9FiRQRtoJM19Boc430w31M32oKo$
>
>
> ------------------------------------------------------------------------
>
>
> 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
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240209/de33ef81/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240209/de33ef81/attachment-0001.p7s>