[Openid-specs-ab] (Draft) AB/Connect WG Meeting Notes (2018-01-22)

Nat Sakimura sakimura at gmail.com
Tue Jan 23 00:06:49 UTC 2018


AB/Connect WG Meeting Notes (2018-01-22)

Date & Time: 2018-01-22 23:00 UTC

Location: GoToMeeting https://www3.gotomeeting.com/join/695548174

Agenda

   - 1.   Roll Call
   <https://bitbucket.org/openid/connect/wiki/AB_meeting_notes_2018-01-22#rst-header-roll-call>
   - 2.   Native SSO for Mobile Apps (George)
   <https://bitbucket.org/openid/connect/wiki/AB_meeting_notes_2018-01-22#rst-header-native-sso-for-mobile-apps-george>
      - 2.1.   Qs and As
      <https://bitbucket.org/openid/connect/wiki/AB_meeting_notes_2018-01-22#rst-header-qs-and-as>
   - 3.   New Issues
   <https://bitbucket.org/openid/connect/wiki/AB_meeting_notes_2018-01-22#rst-header-new-issues>
   - 4.   AOB
   <https://bitbucket.org/openid/connect/wiki/AB_meeting_notes_2018-01-22#rst-header-aob>

The meeting was called to order at 23:07 UTC.
1.   Roll Call
<https://bitbucket.org/openid/connect/wiki/AB_meeting_notes_2018-01-22#rst-header-id1>

   - Attending: Nat, George, Edmund, John, Rich
      - Guest:
   - Regrets:

2.   Native SSO for Mobile Apps (George)
<https://bitbucket.org/openid/connect/wiki/AB_meeting_notes_2018-01-22#rst-header-id2>

George explained his draft [1] about Native SSO for Mobile Apps.

[1]
http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180122/303b574a/attachment-0001.pdf

This is a spec that leverages the token-exchange spec to enable mobile apps
signed by the same signing key to share logged in users.

Basically, when an app from the developer (with same signing key) gets
installed on the device, the app looks for the entry by the developer in
the keychain, and if there is not one, it writes a client-generated device
id that includes a cryptographically random component. Then, the app does
all the usual best practice sign into the IdP and gets ID Token, which gets
written into the keychain as well.

When mobile app #2
<https://bitbucket.org/openid/connect/issues/2/standard-411-separate-sentences-into>
starts,
the app #2
<https://bitbucket.org/openid/connect/issues/2/standard-411-separate-sentences-into>
gets
the ID Token from the keychain. Then, it sends the ID Token to the token
exchange endpoint to get a new access token and refresh token minted for
the app #2
<https://bitbucket.org/openid/connect/issues/2/standard-411-separate-sentences-into>
.
2.1.   Qs and As
<https://bitbucket.org/openid/connect/wiki/AB_meeting_notes_2018-01-22#rst-header-id3>

   1. Is there any standardization effort for device IDs?


   1. No. It should be kept open. Only the requirement here is to have a
   random component in it so that it is not guessable.


   1. Does it not return the iss? It seems to be a best practice to return
   all the involved endpoints explicitly.


   1. No. The token exchange spec does not return one.


   1. Should not the app just get a new consent if the scope is bigger than
   the original?


   1. Since there is no channel open with the user at the time, it is
   returning the error. However, it may be a good idea to condition it that
   "if the app has no way of obtaining consent out of band". The app may be
   able to obtain the consent for example via User Questioning API.

3.   New Issues
<https://bitbucket.org/openid/connect/wiki/AB_meeting_notes_2018-01-22#rst-header-id4>

There were no new issues.
4.   AOB
<https://bitbucket.org/openid/connect/wiki/AB_meeting_notes_2018-01-22#rst-header-id5>

John is going to get hold of Mike to discuss the alignment between JWS and
draft-cavage-http-signatures.

   - The meeting was adjourned at 13:39 UTC.



-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180123/cc98eac4/attachment.html>


More information about the Openid-specs-ab mailing list