[Openid-specs-ab] Fwd: Submission: Native SSO for Mobile Apps (txt and xml)

George Fletcher gffletch at aol.com
Mon Jan 7 23:22:28 UTC 2019


Per the working group call today, bumping to the top of the list.


-------- Forwarded Message --------
Return-Path: 	<openid-specs-ab-bounces at lists.openid.net>
Received: 	from silver.osuosl.org (mpq410.aol.prodcr.mail.ne1.yahoo.com 
[140.211.166.136]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA 
(256/256 bits)) (No client certificate requested) by 
mtaiw-mbd02.mx.aol.com (Internet Inbound) with ESMTPS id 15F89700000B2 
for <gffletch at aol.com>; Fri, 22 Jun 2018 13:30:26 -0400 (EDT)
X-Apparently-To: 	gffletch at aol.com; Fri, 22 Jun 2018 17:30:25 +0000
Date: 	Fri, 22 Jun 2018 13:30:08 -0400
User-Agent: 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) 
Gecko/20100101 Thunderbird/52.8.0
Subject: 	[Openid-specs-ab] Submission: Native SSO for Mobile Apps (txt 
and xml)
From: 	George Fletcher via Openid-specs-ab 
<openid-specs-ab at lists.openid.net>
Reply-To: 	George Fletcher <gffletch at aol.com>
Sender: 	"Openid-specs-ab" <openid-specs-ab-bounces at lists.openid.net>



Per the notes from Thursday's OpenID Connect working group call, here 
are text and xml formatted version of the Native SSO for Mobile apps spec.

Please note, the core text is here but this is no where near final. Note 
that the text for additions for dynamic client registration and other 
IANA registrations are text from the "front channel logout" spec. I left 
the sections there as they will likely be needed.

The purpose here is to get the core text in the proper format.

Thanks,
George



-- 
Identity Standards Architect
Verizon Media                     Work: george.fletcher at oath.com
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

-------------- next part --------------




                                                             G. Fletcher
                                                                    Oath
                                                           June 11, 2018


        OpenID Connect Native SSO for Mobile Apps 1.0 - draft 02
                 openid-connect-native-sso-1_0-draft-02

Abstract

   OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
   protocol.  It enables Clients to verify the identity of the End-User
   based on the authentication performed by an Authorization Server, as
   well as to obtain basic profile information about the End-User in an
   interoperable and REST-like manner.

   This document describes a current best practice that allows a mobile
   app to share the identity/authentication obtained by a different
   mobile app where both apps are issued by the same vendor.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Notation and Conventions . . . . . . . . . .   2
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Abstract Flow . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Native App Authorization Extensions . . . . . . . . . . . . .   4
     3.1.  Authorization Request . . . . . . . . . . . . . . . . . .   4
     3.2.  Device Secret . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Token Request . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  Token Response  . . . . . . . . . . . . . . . . . . . . .   5
   4.  Token Exchange Profile for Native SSO . . . . . . . . . . . .   6
     4.1.  OAuth2 Token Exchange Profile . . . . . . . . . . . . . .   6
     4.2.  Token Exchange Request  . . . . . . . . . . . . . . . . .   8
     4.3.  Native SSO Processing Rules . . . . . . . . . . . . . . .   8
     4.4.  Token Exchange Response . . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  JSON Web Token Claims Registration  . . . . . . . . . . .  10
       6.1.1.  Registry Contents . . . . . . . . . . . . . . . . . .  10
     6.2.  OAuth Dynamic Client Registration Metadata Registration .  10
       6.2.1.  Registry Contents . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  13
   Appendix B.  Document History . . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13



Fletcher                Expires December 13, 2018               [Page 1]


              OpenID Connect Native SSO for Mobile Apps 1.0    June 2018


1.  Introduction

   OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
   [RFC6749] protocol.  It enables Clients to verify the identity of the
   End-User based on the authentication performed by an Authorization
   Server, as well as to obtain basic profile information about the End-
   User in an interoperable and REST-like manner.

   As the industry moves to a more mobile oriented environment, vendors
   need a way to share identity across the multiple mobile apps they
   deploy.  While the current OAuth2 best practice allows for SSO across
   any mobile app by sharing the session cookies in the system browser,
   this has risks such as a user clearing their system browser of
   cookies (possibly as requested by a customer care agent) or using
   private browsing on iOS and Android.  On most mobile platforms,
   mobile apps signed by the same vendor certs can share information via
   the system "keychain (Account Manager on Android)".

   This document specifies a new scope, extends the token endpoint and
   profiles the OAuth2 token exchange [OAuth2.TokenExchange] spec
   allowing mobile apps to share identity (SSO) between apps produced
   and signed by the same vendor (i.e. signed with the same vendor
   cert).

1.1.  Requirements Notation and Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

   In the .txt version of this specification, values are quoted to
   indicate that they are to be taken literally.  When using these
   values in protocol messages, the quotes MUST NOT be used as part of
   the value.  In the HTML version of this specification, values to be
   taken literally are indicated by the use of "this fixed-width font".

1.2.  Terminology

   This specification uses the terms "Authorization Server", "Client",
   "Client Identifier", and "Redirection URI" defined by OAuth 2.0
   [RFC6749], the term "User Agent" defined by RFC 7230 [RFC7230], the
   term "native app" defined by RFC 8252 [RFC8252] and the terms defined
   by OpenID Connect Core 1.0 [OpenID.Core].

   This specification also defines the following terms:

   Device Secret



Fletcher                Expires December 13, 2018               [Page 2]


              OpenID Connect Native SSO for Mobile Apps 1.0    June 2018


      Opaque value to the client, issued by the Authorization Server,
      that uniquely identifies the device instance and provides
      credentials for the device.

   Session ID
      Identifier for a Session.

2.  Abstract Flow

   +----------+     +----------+      +-----------+      +------------+
   |  Native  |     |  Native  |      |  System   |      |            |
   |  App     |     |  App     |      |  Browser  |      |    AS      |
   |  #1      |     |  #2      |      |           |      |            |
   +----+-----+     +----+-----+      +-----+-----+      +-----+------+
        |                |                  |                  |
        | [1] Start OIDC AuthN              |                  |
        +----------------+----------------> |                  |
        |                |                  | [2] /authorize   |
        |                |                  +----------------> |
        |                |                  |                  |
        |                |                  |   [3] authenticate
        |                |                  | <----------------|
        |                |                  |                  |
        |                |                  | [4] user creds   |
        |                |                  +----------------> |
        |                |                  |                  |
        |                |                  |  [5] callback    |
        |                |                  | <----------------+
        |  [6] callback with code           |                  |
        | <--------------+------------------+                  |
        |                |                  |                  |
        |  [7] exchange code for tokens     |                  |
        +----------------+-----------------------------------> |
        |                |                  |                  |
        |     [8] tokens (including device_secret)             |
        | <--------------+------------------+------------------+
        |                |                  |                  |
        |                |                  |                  |
        |                |                  |                  |
        +                +                  +                  +


   Steps [1] - [8] are the standard OpenID Connect authorization_code
   flow with the following extensions.  In step 2, the "device_sso"
   scope is specified signifying that the client is requesting a
   "device_secret" to be returned when the code is exchanged for tokens.





Fletcher                Expires December 13, 2018               [Page 3]


              OpenID Connect Native SSO for Mobile Apps 1.0    June 2018


   +----------+     +----------+      +-----------+      +------------+
   |  Native  |     |  Native  |      |  System   |      |            |
   |  App     |     |  App     |      |  Browser  |      |    AS      |
   |  #1      |     |  #2      |      |           |      |            |
   +----+-----+     +----+-----+      +-----+-----+      +-----+------+
        |                |                  |                  |
        |                |                  |                  |
        |                | [9] token exchange                  |
        |                +------------------+----------------> |
        |                |                  |                  |
        |                |                  |                  |
        |                |    [10] refresh, access, [device_secret]
        |                | <----------------+------------------|
        |                |                  |                  |
        |                |                  |                  |
        |                |                  |                  |
        +                +                  +                  +


   Step [9] invokes the /token endpoint with the token exchange profile
   passing the id_token obtained from the shared device storage, the
   client_id and the device secret.

   Step [10] returns the SSO generated refresh and access tokens for
   Native App #2.

3.  Native App Authorization Extensions

   The following sections describe the extensions required to the
   standard OIDC Authentication flow which will enable a second mobile
   app to share the authentication of the first mobile app where both
   mobile applications are signed by the same vendor certificates.

3.1.  Authorization Request

   This specification defines a new scope value that is used to convey
   to the Authorization Server that when the code is exchanged for a
   token, a new "device_secret" will be returned in addition to the
   other tokens identified as part of the authorization request.

   The new scope value is defined as "device_sso".  When this scope is
   present on the authorization request, when the code is exchanged for
   tokens, a new device_secret will be returned.








Fletcher                Expires December 13, 2018               [Page 4]


              OpenID Connect Native SSO for Mobile Apps 1.0    June 2018


3.2.  Device Secret

   The device secret contains relevant data to the device and the
   current users authenticated with the device.  The device secret is
   completely Opaque to the client and as such it is RECOMMENDED that
   the device secret be implemented as a JWE encrypted for the
   Authorization Server.

   In the context of this extension the device secret may be shared
   between mobile apps that can obtain the value via the shared security
   mechanism (e.g. keychain on iOS).  If a mobile app requests a device
   secret via the "device_sso" scope and a "device_secret" exists, then
   the client MUST provide the "device_secret" on the request to the
   /token endpoint to exchange code for tokens.  The client MAY provide
   the "device_secret" to the /token endpoint during refresh token
   requests.

   The exact construction of the "device_secret" is out of scope for
   this specification.

3.3.  Token Request

   During a normal user authentication via the system browser, after the
   mobile app receives the code and state response from the
   Authorization Server, this spec defines the following additional
   parameters to the /token endpoint for the authorization_code
   grant_type.

   device_secret
      OPTIONAL.  This token SHOULD be provided if the client requested
      the "device_sso" scope and the client already has a
      "device_secret" available.  If no "device_secret" is specified and
      the refresh_token contains the "device_sso" scope, a new
      "device_secret" will be generated.

3.4.  Token Response

   When the authorization server receives the _device_secret_ value it
   MUST process the authorization_code grant type per the OIDC spec with
   the following additions applying to the id_token.

   1.  Add a ?ds_hash? claim to the id_token to represent a function of
       the device identifier.

       ds_hash
          REQUIRED.  The ds_hash value provides a binding between the
          id_token and the issued device_secret.  The exact binding
          between the ds_hash and device_secret is not specified by this



Fletcher                Expires December 13, 2018               [Page 5]


              OpenID Connect Native SSO for Mobile Apps 1.0    June 2018


          profile.  As this binding is managed solely by the
          Authorization Server, the AS can choose how to protect the
          relationship between the id_token and device_secret.

   2.  Add a session id to the id_token that represents the user?s
       current authentication session.

       sid
          REQUIRED.  A string that uniquely identifies this user?s
          authentication ?session?. This value can be used in logout
          flows as well as the flow this spec is describing.  For mobile
          apps where there is not explicit ?browser authentication? this
          value SHOULD represent the underlying session associated with
          the refresh_token.

   Note that the implementation of this spec and the specification of
   the ds_hash and sid value MUST NOT leak any data that would provide a
   security advantage to an attacker who gains access to the id_token.

   When the authorization server receives the device_secret it must
   validate the token.  If the token is invalid it must be discarded and
   the request processed as if no device_secret was specified.

   If the authorization request included the device_sso scope then the
   authorization server MUST return a device_secret in the response.
   The device_secret is returned in the ?device_token? claim of the
   returned JSON data.

   If no devices_secret is specified, then the AS MUST generate the
   token.  If a device_secret is specified and is valid, the AS MUST
   update the device_secret as necessary.

4.  Token Exchange Profile for Native SSO

   This section profiles the OAuth2 Token Exchange
   [OAuth2.TokenExchange] spec and describes the processing rules used
   to exchange a previous authentication for new refresh and access
   tokens requested by a mobile app created by the same vendor as the
   first mobile app and both apps signed by the same developer key.

4.1.  OAuth2 Token Exchange Profile

   The client MUST use the HTTP Basic Authentication method from RFC
   6749 to authenticate the request to the token endpoint.  Note that
   since the mobile app is using PKCE, the mobile app does not have a
   secret and will only specify the client_id in the HTTP Authorization
   header.




Fletcher                Expires December 13, 2018               [Page 6]


              OpenID Connect Native SSO for Mobile Apps 1.0    June 2018


   This profile defines the use of the following token exchange
   parameters.

   grant_type
      REQUIRED.  The value MUST be urn:ietf:params:oauth:grant-
      type:token-exchange

   audience
      REQUIRED.  This parameter defines the logical purview of the
      returned tokens.  For the purposes of this profile, this value
      MUST be the issuer URI for the OpenID Provider that issued the
      id_token used in this profile.

   subject_token
      REQUIRED.  This parameter MUST contain the id_token obtained by
      the first native app.  The id_token is used in the same manner as
      id_token_hint to identify the user to SSO into the invoking native
      app.

   subject_token_type
      REQUIRED.  This parameter MUST contain the value:
      urn:ietf:params:oauth:token-type:id_token

   actor_token
      REQUIRED.  This value defines the actor making the request which
      in this case is the device_secret issued to the device of the
      native application making the request.  The device_secret MUST be
      presented per the definition of the urn:x-oath:params:oauth:token-
      type:device-secret token identifier described below.

   actor_token_type
      REQUIRED.  This value MUST be: urn:x-oath:params:oauth:token-
      type:device-secret

   scope
      OPTIONAL.  The scopes required by the requesting native
      application.

   requested_token_type
      OPTIONAL.  The desired token(s) to be returned.

   This profile also defines the following token type identifiers.

   urn:x-oath:params:oauth:token-type:device-secret
      This token type identifier is used to describe the device_secret
      specified in the actor_token parameter.





Fletcher                Expires December 13, 2018               [Page 7]


              OpenID Connect Native SSO for Mobile Apps 1.0    June 2018


4.2.  Token Exchange Request

   When a mobile app wants to request ?native SSO? (i.e. obtain refresh
   and access tokens for an already signed in user) it makes a standard
   OAuth2 /token endpoint request following the profile for Token
   Exchange defined above.

    POST /token HTTP/1.1
    Host: as.example.com
    Authorization: Basic ZGZhZGYyMzUyNDU0Og
    ...
    grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
    &audience=https%3A%3F%3Flogin.aol.com&subject_token=<id_token>
    &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aid-token
    &actor_token=95twdf3w4y6wvftw35634t
    &actor_token_type=urn%3Ax-oath%3Aparams%3Aoauth%3Atoken-type%3Adevice-secret

   The client_id in this request is sent via the HTTP Basic
   Authentication method using the HTTP Authorization header.

4.3.  Native SSO Processing Rules

   When the authorization server receives a request at the token
   endpoint conforming to this profile it MUST perform the following
   checks before issuing any tokens.

   1.  Validate the device_secret to ensure the token is still valid.
       The format of this secret is defined by the Authorization server
       and is out of scope for this specification.

   2.  Verify that the binding between the id_token and the
       device_secret as defined in the extension to the /token response.

   3.  Verify that the session id in the id_token (?sid? claim) is still
       valid.  If the session is no longer valid, the AS MUST return an
       error of ?invalid_grant?.

   4.  Validate that the client requesting native SSO is authorized to
       do so.  The AS SHOULD maintain a list of client_ids that can
       share user authentications.  For example, the AS MAY take the
       ?aud? claim from the id_token and the client_id from the token
       request and ensures that both client_ids are allowed to share
       user authentications.

   5.  The AS SHOULD verify that the scopes requested by the client in
       the token request (either default scopes or explicitly specified
       in the optional ?scope? parameter) do NOT require explicit user
       consent.  If any requested scopes require explicit user consent



Fletcher                Expires December 13, 2018               [Page 8]


              OpenID Connect Native SSO for Mobile Apps 1.0    June 2018


       the AS SHOULD fail the request and return an error of
       ?invalid_scope?.

   Based on the AS definition of the device_secret, the AS may perform
   addition check to ensure the security of the request.  Provided the
   above criteria is met, the AS will issue a normal Token Response
   object containing a refresh_token, access_token and id_token issued
   to the client_id of the mobile app making the request.  The session
   associated with the new refresh_token SHOULD be the same as that used
   to verify the validity of the SSO exchange.  If that session expires,
   all refresh_tokens associated with it MUST be invalidated.

4.4.  Token Exchange Response

   The Token Exchange response for this profile has the following
   characteristics:

   access_token
      REQUIRED.  This response field contains the access token issued to
      the mobile client identified by the client_id sent in the
      Authorization header.

   issued_token_type
      REQUIRED.  This value of this parameter MUST be:
      urn:ietf:params:oauth:token-type:access_token

   token_type
      REQUIRED.  The value of this parameter MUST be "bearer".

   expires_in
      REQUIRED.  Identifies when the access_token expires.

   scope
      OPTIONAL.  Follows the token exchange spec definition.

   refresh_token
      REQUIRED.  A refresh_token that the mobile app can use to obtain
      additional access_tokens when the access_token expires.

   device_secret
      REQUIRED.  The AS MUST return either a new or updated
      device_secret in the response.

   In the case of any errors, the AS MUST return a valid OAuth2 Error
   response as described in Section 2.2.2 of the Token Exchange spec.






Fletcher                Expires December 13, 2018               [Page 9]


              OpenID Connect Native SSO for Mobile Apps 1.0    June 2018


    HTTP/1.1 200 OK
    Content-Type: application/json;charset=UTF-8
    Cache-Control: no-store
    Pragma: no-cache

    {
      "access_token":"2YotnFZFEjr1zCsicMWpAA",
      "Issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
      "token_type":"bearer",
      "expires_in":3600,
      "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
      "device_secret":"casdfgarfgasdfg"
    }

5.  Security Considerations

   Sufficient care must be made to protect the "device_secret".  The
   device secret SHOULD be encrypted by the Authorization Service and
   periodically refreshed via the mechanisms described in this
   specification.

6.  IANA Considerations

6.1.  JSON Web Token Claims Registration

   This specification registers the following Claim in the IANA "JSON
   Web Token Claims" registry [IANA.JWT.Claims] established by [JWT].

6.1.1.  Registry Contents

   o  Claim Name: "sid"
   o  Claim Description: Session ID
   o  Change Controller: OpenID Foundation Artifact Binding Working
      Group - openid-specs-ab at lists.openid.net
   o  Specification Document(s): OPLogout of this specification

6.2.  OAuth Dynamic Client Registration Metadata Registration

   This specification registers the following client metadata
   definitions in the IANA "OAuth Dynamic Client Registration Metadata"
   registry [IANA.OAuth.Parameters] established by [RFC7591]:

6.2.1.  Registry Contents

   o  Client Metadata Name: "frontchannel_logout_uri"
   o  Client Metadata Description: RP URL that will cause the RP to log
      itself out when rendered in an iframe by the OP




Fletcher                Expires December 13, 2018              [Page 10]


              OpenID Connect Native SSO for Mobile Apps 1.0    June 2018


   o  Change Controller: OpenID Foundation Artifact Binding Working
      Group - openid-specs-ab at lists.openid.net
   o  Specification Document(s): RPLogout of this specification

   o  Client Metadata Name: "frontchannel_logout_session_required"
   o  Client Metadata Description: Boolean value specifying whether the
      RP requires that a "sid" (session ID) query parameter be included
      to identify the RP session with the OP when the
      "frontchannel_logout_uri" is used
   o  Change Controller: OpenID Foundation Artifact Binding Working
      Group - openid-specs-ab at lists.openid.net
   o  Specification Document(s): RPLogout of this specification

7.  References

7.1.  Normative References

   [IANA.JWT.Claims]
              IANA, "JSON Web Token Claims",
              <http://www.iana.org/assignments/jwt>.

   [IANA.OAuth.Parameters]
              IANA, "OAuth Parameters",
              <http://www.iana.org/assignments/oauth-parameters>.

   [OAuth2.TokenExchange]
              Campbell, B., "OAuth 2.0 Token Exchange", June 2018,
              <https://tools.ietf.org/html/
              draft-ietf-oauth-token-exchange-14>.

   [OpenID.BackChannel]
              Jones, M. and J. Bradley, "OpenID Connect Back-Channel
              Logout 1.0", January 2017, <http://openid.net/specs/
              openid-connect-backchannel-1_0.html>.

   [OpenID.Core]
              Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0", November 2014,
              <http://openid.net/specs/openid-connect-core-1_0.html>.

   [OpenID.Discovery]
              Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
              Connect Discovery 1.0", November 2014,
              <http://openid.net/specs/
              openid-connect-discovery-1_0.html>.






Fletcher                Expires December 13, 2018              [Page 11]


              OpenID Connect Native SSO for Mobile Apps 1.0    June 2018


   [OpenID.Registration]
              Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
              Dynamic Client Registration 1.0", November 2014,
              <http://openid.net/specs/
              openid-connect-registration-1_0.html>.

   [OpenID.Session]
              Sakimura, N., Bradley, J., Jones, M., de Medeiros, B.,
              Mortimore, C., and E. Jay, "OpenID Connect Session
              Management 1.0", January 2017,
              <http://openid.net/specs/openid-connect-session-1_0.html>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <https://www.rfc-editor.org/info/rfc7230>.

   [RFC8252]  Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
              BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,
              <https://www.rfc-editor.org/info/rfc8252>.

7.2.  Informative References

   [JWT]      Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <http://tools.ietf.org/html/rfc7519>.

   [RFC7591]  Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
              P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
              RFC 7591, DOI 10.17487/RFC7591, July 2015,
              <https://www.rfc-editor.org/info/rfc7591>.






Fletcher                Expires December 13, 2018              [Page 12]


              OpenID Connect Native SSO for Mobile Apps 1.0    June 2018


Appendix A.  Acknowledgements

   The OpenID Community would like to thank the following people for
   their contributions to this specification:

      Nat Sakimura, Nomura Reserach Institute, Ltd.

Appendix B.  Document History

   [[ To be removed from the final specification ]]

   -00

   o  Initial Draft.

Author's Address

   George F. Fletcher
   Oath

   Email: george.fletcher at oath.com






























Fletcher                Expires December 13, 2018              [Page 13]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openid-connect-native-sso-1_0.xml
Type: text/xml
Size: 33622 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190107/40bb2b11/attachment-0001.xml>
-------------- next part --------------
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab



More information about the Openid-specs-ab mailing list