<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi all,<br>
<br>
@Mike: first of all let me thank you for taking the burden and
rework the whole document structure. I think the new structure is a
major leap forward for OpenID Connect.<br>
<br>
I focused my review on the new core specification. Please find my
comments below. <br>
<br>
I won't attend IIW but will attend IETF-88. So, if needed, we can
talk through my comments there.<br>
<br>
Best regards,<br>
Torsten.<br>
<br>
1. Introduction<br>
<br>
I would suggest to a reference to RFC 6749 in the first sentence. It
probably also makes sense to explicitly point out that the reader is
expected to be familiar with RFC 6749 and RFC 6750 as well as other
IETF I-Ds (notably JOSE, JWT and JWT Assertion Profile).<br>
<br>
1.3. Overview<br>
The flow description is a good starting point for readers. I would
suggest to add the following information in this section:<br>
<br>
- OpenID Connect authentication is basically an extension to the
standard OAuth authorization process. This extension is defined for
most OAuth grant types.<br>
- Clients wishing to acquire identity information indicate this by
sending the scope value "openid" as part of the authorization
request parameters. (There are much more parameters used to control
the process but this is the "main switch".)<br>
- Such a client is also called relying party (RP). An authorization
server also supporting OpenID Connect is called OpenID Provider
(OP). <br>
<br>
Adding this information will help the reader to understand the way
connect utilizes/integrates into OAuth. <br>
<br>
I would also suggest to move the definition (syntax and contents) of
the ID Token here and make it section 1.4 because this is THE core
concepts used throughout the specification. It's introduction in
section 2.1.3.6 is to late (in my opinion) because it is cited
roughly 20 times in previous sections.<br>
<br>
2. Authentication<br>
"The Authorization Code Flow is suitable for Clients that can
securely maintain a Client Secret between themselves and the
Authorization Server ..." - this is confusing since public clients
can use the code as well. The key benefits of this grant type in my
opinion are:<br>
- AS _can_ authenticate clients<br>
- AS _can_ return refresh tokens<br>
- simplest way for web application backends to acquire tokens<br>
That's why is best suited for web applications and native apps. <br>
<br>
Proposal:<br>
"The Authorization Code Flow is appropriate for web applications and
native apps as it allows to authenticate clients and obtain refresh
tokens whereas the implicit flow does not support these features."<br>
Or just remove the assessment of OAuth grant types and leave it to
the implenentors to carry out their assessment.<br>
<br>
2.1. Authentication using the Authorization Code Flow<br>
<br>
OLD: "This provides the benefit of not exposing the Access Token to
the Resource Owner ..."<br>
<br>
The same indeed holds for the ID Token, which is more important from
a security perspective.<br>
<br>
NEW: "This provides the benefit of not exposing the Access Token and
the ID Token to the Resource Owner ..." <br>
NEW (alternative): "This provides the benefit of not exposing any
Token to the Resource Owner ..." <br>
<br>
2.1.1. Authorization Code Flow Steps<br>
<br>
OLD: "8. Client validates the tokens and retrieves the End-User's
subject identifier."<br>
<br>
I assume the client is supposed to validate the ID token, only?<br>
<br>
NEW: "8. Client validates the ID token and retrieves the End-User's
subject identifier." <br>
<br>
2.1.2.1. Authorization Request<br>
<br>
"When the Client wishes to access a Protected Resource and the
End-User Authorization has not yet been obtained, the Client
prepares an Authorization Request to the Authorization Endpoint" -
Why is this relevent in this context? I suggest to remove this
sentence.<br>
<br>
"An Authorization Request is a message sent from an RP to the OP's
Authorization Endpoint. It is an extended OAuth 2.0 [RFC6749]
Authorization Request. Section 4.1.1 and 4.2.1 of OAuth 2.0
[RFC6749] define the OAuth 2.0 Authorization Request parameters." -
Why Authorization Request? Shouldn't this be called an
"Authentication Request"?<br>
<br>
"Communication with the Authorization Endpoint MUST utilize TLS. See
Section 15.17 for more information on using TLS.<br>
Authorization Servers MUST support the use of the HTTP GET and POST
methods defined in RFC 2616 [RFC2616] at the Authorization
Endpoint.Clients MAY use the HTTP GET or POST methods to send the
Authorization Request to the Authorization Server. If using the HTTP
GET method, the request parameters are serialized using URI Query
String Serialization, perSection 12.1. If using the HTTP POST
method, the request parameters are serialized using Form
Serialization, per Section 12.2." <br>
<br>
Seems to be standard OAuth stuff, I suggest to remove it. <br>
<br>
- redirect_uri Parameter <br>
<br>
"This URI MUST exactly match one of the redirect_uris registered for
the Client" - Why is the redirect_uri validation more restrictive
than <a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc6749#section-3.1.2.2">http://tools.ietf.org/html/rfc6749#section-3.1.2.2</a>?<br>
<br>
"When using this flow, the redirection URI MAY use the http scheme,
provided that the Client Type is confidential, as defined in Section
2.1 of OAuth 2.0; otherwise, it MUST use the https scheme" - This,
surprisingly enough, is relaxed in comparison to
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc6749#section-10.5">http://tools.ietf.org/html/rfc6749#section-10.5</a>.<br>
<br>
RFC 6749 states: "Authorization codes operate as plaintext bearer
credentials, used to verify that the resource owner who granted
authorization at the authorization server is the same resource owner
returning to the client to complete the process. Therefore, if the
client relies on the authorization code for its own resource owner
authentication, the client redirection endpoint MUST require the use
of TLS."<br>
<br>
Why is Connect, in this particular case, less restrictive than
OAuth?<br>
<br>
- nonce Parameter <br>
<br>
"One method to achieve this is to store a random value as a signed
session cookie, and pass the value in the nonce parameter. In that
case, the nonce in the returned ID Token can be compared to the
signed session cookie to detect ID Token replay by third parties." -
I would recommend to move this text into an "implementation note"
section<br>
<br>
id_token_hint Parameter - "Previously issued ID Token passed to the
Authorization Server .." issued by the AS being requested? or any
AS? I assume by the same AS<br>
NEW: "ID Token previously issued by this Authorization server to the
client ..."<br>
<br>
"... it SHOULD return a login_required error." - Does this mean the
OP shall try to authenticate the user account identified by the ID
token and refuses authentication otherwise? This sounds more like a
requirement than a hint. <br>
<br>
"When possible, an id_token_hint SHOULD be present when prompt=none
is used and an invalid_request error MAY be returned if it is not;
however, the server SHOULD respond successfully when possible, even
if it is not present." - Why is the login hint recommended for this
prompt value? checkid_immediate in OpenID 2.0 worked very well w/o a
hint?<br>
<br>
2.1.2.2. Authorization Request Validation<br>
<br>
"3. If the sub (subject) Claim is requested with a specific value
for the ID Token ...." The meaning of the text is unclear to me. How
is a specific sub value requested? by the login_hint or the
id_token_hint?<br>
<br>
"As specified in OAuth 2.0 [RFC6749], Authorization Servers SHOULD
ignore unrecognized request parameters.<br>
<br>
If the Authorization Server encounters any error, it MUST return an
error response."<br>
<br>
Standard OAuth stuff, I recommend to remove it.<br>
<br>
2.1.2.4. Authorization Server Obtains End-User
Consent/Authorization<br>
<br>
"When permitted by the request parameters used, this MAY be done
through an interactive dialogue with the End-User ..." - What if the
parameters do not allow for an interactive dialogue, e.g.
prompt==none? I assume an error response with return code
consent_required or interaction_required is appropriate. I would
prefer interaction_required because to RP does not need to know
more. <br>
<br>
2.1.2.5. Authorization Successful Response<br>
<br>
This is a vanilla OAuth 2.0 response, right? I would suggest to just
say so.<br>
<br>
BTW: This piece of text is not applicable to the code grant type:
"This specification only describes OAuth 2.0 Bearer Token Usage
[RFC6750]. The OAuth 2.0 response parameter token_type MUST be set
to Bearer unless another Token Type has been negotiated with the
Client." <br>
<br>
2.1.3. Tokens Endpoint<br>
<br>
"Clients MUST use the HTTP POST method to make requests to the Token
Endpoint. Request parameters are added using Form Serialization, per
Section 12.2. The Token Endpoint MUST support the use of the HTTP
POST method defined in RFC 2616 [RFC2616] at the Token Endpoint.<br>
<br>
Communication with the Token Endpoint MUST utilize TLS. See Section
15.17 for more information on using TLS.<br>
<br>
All Token Endpoint responses that contain tokens, secrets, or other
sensitive information MUST include the following HTTP response
header fields and values: ..."<br>
<br>
This seems to be standard OAuth stuff. I recommend to remove it.<br>
<br>
2.1.3.1. Token Request<br>
<br>
"To obtain an ID Token, Access Token, or Refresh Token, the Client
MUST authenticate to the Token Endpoint using the authentication
method registered for its client_id, as described in Section 8 ..."
- At this point the reader is not familiar with the different
authentication methods supported by an OpenID OP. I therefore
suggest to move the client authentication section before the
authentication section (e.g. make it a section 1.5).<br>
<br>
2.1.3.2. Token Request Validation<br>
<br>
The whole sections seems to re-phrase standard OAuth stuff. I
recommend to remove it. <br>
<br>
2.1.3.3. Token Successful Response<br>
<br>
"Servers SHOULD support OAuth 2.0 Bearer Token Usage [RFC6750] for
interoperability" - I think this topic is better covered in the MTI
section.<br>
<br>
"the following parameters MUST be included in the response if the
grant_type value is authorization_code and the Authorization Request
scope parameter contains openid:" - Seems to be redundant since this
whole section is about exactly this use case. I recommend to remove
this text. Same holds true for the following text<br>
<br>
"An id_token MUST be returned when the grant_type value is
authorization_code and MAY be returned when other grant types are
used."<br>
<br>
2.1.3.6. ID Token<br>
<br>
That's the key elements of OpenID Connect! As already stated, I
recommend to move the (full) description of its content and syntax
to section 1 (section 1.4). I think this will facilitate
readability. The validation rules should stay in the sections of the
respective grant types.<br>
<br>
2.1.3.7. ID Token Validation<br>
<br>
"1. If the Client has provided an id_token_encrypted_response_alg
parameter during Registration, decrypt the ID Token using the key
pair specified during Registration." - text depends on dynamic
registration and should therefore be generalized. <br>
NEW: "1. If the ID Token is encrypted, the Client first decrypts it
using the key agreed upon with the authorization server."<br>
<br>
"5. If the id_token is received via direct communication between the
Client and the Token Endpoint, the TLS server validation MAY be used
to validate the issuer in place of checking the token signature. The
Client MUST validate the signature of all other ID Tokens according
to JWS [JWS] using the algorithm specified in the alg parameter of
the JWT header." - text seems rather generic. As this is about the
code flow, the ID token is received via direct communication, so the
text can be simplified.<br>
NEW: "5. Since the ID token is received via direct communication,
the TLS server validation MUST be used to validate the issuer in
place of checking the token signature."<br>
<br>
Steps 6-8 can be removed.<br>
<br>
2.1.3.8. Access Token Validation<br>
<br>
I would recommend to add the text from section 2.2.2.9. because this
is the first point where the concept is used.<br>
<br>
a_hash validation is mentioned. What's about c_hash validation?<br>
<br>
2.2. Authentication using the Implicit Flow<br>
<br>
"...which may expose them to the Resource Owner and other
applications that have access to the Resource Owner's User-Agent." -
I recommend to add: "In contrast to the authorization code flow,
this requires additional security mechanisms (described below) to
detect falsified ID tokens."<br>
<br>
2.2.2.1. Authorization Request<br>
see comments regarding redirect_uri and nonce for section 2.1.2.1<br>
<br>
2.2.2.2 - 2.2.2.4 - I recommend to state in section 2.2.2 that those
steps are performed in the same manner as for the code flow and to
remove these section?<br>
<br>
2.2.2.5. Authorization Successful Response<br>
<br>
access_token Parameter - "Access Token for the UserInfo Endpoint." -
In contrast to section 2.1.3.3, this section also described standard
OAuth response parameters. I don't think this is needed. Moreover,
the term "User Info" is used before it is really introduced. In my
opinion, authentication should not talk about user info. The access
token returned as part of the authentication result might suited for
interactions with any protected resource, including user info. <br>
<br>
2.2.2.7. Redirect URI Fragment Handling<br>
<br>
This section needs a bit more of context and description. While the
introduction of 2.2 states: "The Implicit Flow is mainly used by
Clients implemented in a browser using a scripting language", this
section suddenly _requires_ the client to send data to a web server
("The Client MUST provide ...").<br>
<br>
First of all, I don't understand the MUST.<br>
<br>
Second, a description is needed of the different patterns, scripting
clients vs. scripted frontends of server-based web-application (here
the implicit grant offers better performance and scalability at the
cost of a more complex client implementation. Therefore,
implementation advices are given. <br>
<br>
I also think this section should be part of an "implementation note"
section.<br>
<br>
2.2.2.11. ID Token Validation<br>
<br>
Text around signature validation should be moved from 2.1.3.7 to
this section as it is required for the implicit grant (in contrast
to code).<br>
<br>
2.3. Authentication using the Hybrid Flow<br>
<br>
2.3.2.2.-2.3.2.4. can be removed<br>
<br>
2.3.2.5. Authorization Successful Response<br>
<br>
Again, I would recommend to focus on additional response parameters,
as in section 2.1.3.3<br>
<br>
2.3.2.7. Redirect URI Fragment Handling<br>
<br>
see comment at section 2.2.2.7<br>
<br>
I think 2.3.3.1.-2.3.3.9 can be removed - Instead it should be
stated that for the hybrid flow client and AS must conform to ALL
requirements for code and implicit. <br>
<br>
3. Initiating Login from a Third Party<br>
<br>
I assume this is mainly intended to support OP initiated logins? I
don't think it deserves a top-level section. I would recommend to
make it part of the Authentication section.<br>
<br>
"The Client MAY optionally register [OpenID.Registration] an
initiate_login_uri that can be used by the Authorization Server or
another party to initiate a login for an End-User at the Client." I
assume this feature shall also be supported by OPs w/o dynamic
registration? I therefore suggest to move this text to the dynamic
registration spec. Instead one could state: "The approach utilized
by the 3rd party or the OP to determine the client's respective URL
is out-of-scope of this document."<br>
<br>
Generally, I don't think any meta data element registered via
dynamic registration or discovered via OpenID Discovery should be
specified/mentioned in the core spec. I think the core function must
work w/o both functions in place.<br>
<br>
4. Claims<br>
<br>
"This section specifies how the Client can obtain Claims about the
End-User ..." claims about the authentication process are supported
as well.<br>
NEW: "This section specifies how the Client can obtain Claims about
the End-User and the authentication process ...<br>
<br>
4.1. Requesting Claims using Scope Values<br>
<br>
This is an extension to the authentication part, it should be
specified that way. For example, there is no need to specify the use
of the scope value "openid" again. IMHO it suffices to say that
clients may request access to user data by adding more scope values
in conjunction with "openid".<br>
<br>
4.2. Standard Claims<br>
<br>
I think this section should be the first section as it describes
standard claims on a conceptual level and which ways exist for a
client to retrieve them. <br>
<br>
4.3. UserInfo Endpoint<br>
<br>
I think this section should be merged with Section 4.1 as the scope
values defined there control access to this resource, only. <br>
<br>
4.4. Requesting Claims Locales with the "claims_locales" Request
Parameter<br>
<br>
I would suggest to move this either before 4.1. or after 4.5. as it
seems to be orthogonal to the functions described there.<br>
<br>
4.6. Claim Types<br>
<br>
This seems to be out of order because after a description of how a
client may allocate claims to ID token and user info, this section
again exclusively talks about UserInfo. Is it really the intention
to support aggregated and distributed claims at the User Info
endpoint, only? If so I recommend to move this section before 4.4.
Otherwise, please state that such claims can be provided in the ID
Token as well.<br>
<br>
How is a aggregated or distributed claim requested by a client? <br>
<br>
5. Passing Request Parameters as JWTs<br>
<br>
I would suggest to move this topic into another document. The
features described here allow implementors to achieve higher
security levels and may reduce the request size but I consider them
beyond the scope of a core document.<br>
<br>
6. Self-Issued OpenID Provider<br>
<br>
How mature is the concept? How many implementations exist? Is this
really part of a core specification or rather an extension for
mobile/personal devices? I would opt for making this section a
separate document.<br>
<br>
6.2. Self-Issued OpenID Provider Registration<br>
<br>
"When using a Self-Issued OP, the Client is deemed to have
registered with the OP and obtained following Client Registration
Response." - Does this mean dynamic registration is required for
self-issued ID providing?<br>
<br>
7. Subject Identifier Types<br>
<br>
This section is completely about discovery and registration - it
should go there, consequently.<br>
<br>
8. Client Authentication<br>
<br>
This section provides fundamental information about the client
authentication methods supported/introduced by OpenID Connect. I
would suggest to move it into section 1 (e.g. section 1.5).<br>
<br>
"During Client Registration, the RP (Client) MAY register an
authentication method. " I assume all client authentication methods
shall work even if the OP does not support dynamic registration.
Consequently, this text must be replaced by a general description of
what methods are supported and how the OP is supposed to determine
the right method for a particular client.<br>
<br>
OLD: "During Client Registration, the RP (Client) MAY register an
authentication method. If no method is registered, the default
method of client_secret_basic MUST be used."<br>
NEW: "OpenID connect supports the authentication methods listed
below. The authorization server determines the authentication method
to be used in a particular authorization transaction based on the
client_id. The way client and authorization server negotiate the
authentication method is out of scope of this specification."<br>
<br>
9. Signatures and Encryption<br>
<br>
Most of this section talks about discovery and dynamic registration
- it should go there, consequently.<br>
<br>
I think the core spec needs MTI algorithms and clear definition when
signatures are required. In my opinion, there are two use cases:<br>
- Login via implicit grant<br>
- azp - Login at another AS via ID token<br>
<br>
In both cases, Signing ID Tokens with RSA SHA-256 could be good
baseline. This could be documented in the ID Tokens section or the
MTI section.<br>
<br>
9.3.1. Rotation of Asymmetric Signing Keys<br>
<br>
Isn't this an implementation note?<br>
<br>
10. Offline Access<br>
<br>
Given the description (" that grants access to the End-User's
UserInfo Endpoint ..."), I would say this text can go to the User
Info section. <br>
<br>
11. Using Refresh Tokens<br>
<br>
I think this should go to the authentication section (2.4?), as it
describes usage of the refresh token grant type in the Connect
context.<br>
<br>
11.2. Refresh Successful Response<br>
<br>
"If an ID Token is returned as a result of a token refresh request
..." - Can't we specify the conditions under which an ID token is
returned? Otherwise, an interoperable client does not know what to
expect or how to control the outcome of this request. For the
standard authentication flow, presence of the scope value "openid"
is the trigger. I would suggest to use the same logic for the
refresh token grant type.<br>
<br>
14. Implementation Considerations<br>
<br>
I would suggest to move MTI requirements to another document as it
refers to nearly every document of the OpenID Connect suite. For the
core document, I would suggest to (at most) specify the MTI
requirements for closed systems, only:<br>
- code flow extension<br>
- prompt<br>
- display<br>
- language<br>
<br>
14.1. Mandatory to Implement Features for All OpenID Providers<br>
<br>
"Signing ID Tokens with RSA SHA-256" - I think, in Berlin, we agreed
to not require signatures for simple, static setups using authz
code. We agreed to move this to the MTI section for dynamic OPs.<br>
<br>
14.5. Compatibility Notes<br>
<br>
Isn't such information better covered on the working group page.
Such information typically change more often than the specification
itself.<br>
<br>
14.6. Related Specifications and Implementer's Guides<br>
<br>
same here<br>
-------------------------------------------------------------------------------------------------------------------------<br>
<div class="moz-cite-prefix">Am 15.10.2013 17:18, schrieb Mike
Jones:<br>
</div>
<blockquote
cite="mid:4E1F6AAD24975D4BA5B168042967394377DF7AFD@TK5EX14MBXC287.redmond.corp.microsoft.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:889682530;
mso-list-type:hybrid;
mso-list-template-ids:-1632307396 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:1521317662;
mso-list-type:hybrid;
mso-list-template-ids:907580902 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">I’m pleased to announce that the first
release candidate versions for final OpenID Connect
specifications have been published. The complete set of
specifications has been updated to resolve all issues that had
been filed against the specs being finished.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Please review these this week, in time for
the <a moz-do-not-send="true"
href="http://openid-wg-oct-2013.eventbrite.com/">
in-person working group meeting on Monday</a>. Besides
publishing the specs in the usual formats, I’ve also created a
Word version of the core spec with tracked changes turned on
to facilitate people marking it up with specific proposed text
changes. If you’re in the working group, please <a
moz-do-not-send="true"
href="http://self-issued.info/docs/openid-connect-core-1_0-14.docx">
download it</a> and make any corrections or changes you’d
like to propose for the final specification.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The release candidate spec versions are:<o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><a
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-core-1_0-14.html">http://openid.net/specs/openid-connect-core-1_0-14.html</a><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><a
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-discovery-1_0-18.html">http://openid.net/specs/openid-connect-discovery-1_0-18.html</a><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><a
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-registration-1_0-20.html">http://openid.net/specs/openid-connect-registration-1_0-20.html</a><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><a
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-session-1_0-16.html">http://openid.net/specs/openid-connect-session-1_0-16.html</a><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><a
moz-do-not-send="true"
href="http://openid.net/specs/oauth-v2-multiple-response-types-1_0-09.html">http://openid.net/specs/oauth-v2-multiple-response-types-1_0-09.html</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Also, two implementer’s guides are also
available to serve as self-contained references for
implementers of basic Web-based Relying Parties:<o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l1 level1 lfo2"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><a
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-basic-1_0-29.html">http://openid.net/specs/openid-connect-basic-1_0-29.html</a><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l1 level1 lfo2"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><a
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-implicit-1_0-12.html">http://openid.net/specs/openid-connect-implicit-1_0-12.html</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks to Nat for the early feedback. The
structure of Core has been changed somewhat since -13 to adopt
some of his suggestions.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">
-- Mike<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">P.S. I also posted about this at <a
moz-do-not-send="true"
href="http://self-issued.info/?p=1140">
http://self-issued.info/?p=1140</a> and as @selfissued.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</body>
</html>