[Openid-specs-ab] Call for adoption: Native SSO for Mobile Apps Draft
Nat Sakimura
sakimura at gmail.com
Tue Jan 8 00:17:57 UTC 2019
Thanks, George.
With this, I would like to ask the WG if there are any objections to
adopting it as the new work item.
Please speak up before the end of the weak.
Best,
Nat Sakimura
On Tue, Jan 8, 2019 at 8:22 AM George Fletcher via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:
> 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
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190108/58b8f4b4/attachment.html>
-------------- 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: 34426 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190108/58b8f4b4/attachment.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