[Openid-specs-ab] Issue #898: New Core - 1.2 Terminology - Authentication Request, Authorization Request (openid/connect)

Anthony Nadalin tonynad at microsoft.com
Tue Nov 5 21:21:47 UTC 2013


I’m also concerned with folks stuffing assertions as secrets, that really gets us interop

From: John Bradley [mailto:ve7jtb at ve7jtb.com]
Sent: Tuesday, November 5, 2013 1:05 PM
To: Anthony Nadalin
Cc: Mike Jones; Nat Sakimura; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Issue #898: New Core - 1.2 Terminology - Authentication Request, Authorization Request (openid/connect)

Personally I am not that concerned with the token endpoint response and if that is restricted to access and refresh tokens.   I think the hose is out the door on that.

My concern is around requests to the token endpoint.   It is required by OAuth to be a Form POST.   This is awkward for sending any sort of structured request.

That is one reason we changed the registration endpoint to take a JSON object as the POST body.

It is going to be a total pain in the ass for implementers to have a single base URI that dynamically switches between HTML Form and JSON for input.

That is why I prefer to have a second base URL endpoint for JSON POST, if some tricky server wants to use the same base URL for both thats fine but forcing everyone into that complexity would be a mistake in my opinion.

Mike's proposal would also likely benefit from being a JSON POST rather than key value form encoding.

John B.

On Nov 5, 2013, at 12:32 PM, Anthony Nadalin <tonynad at microsoft.com<mailto:tonynad at microsoft.com>> wrote:


I understand Torsten’s point, the meta issue is what is a token endpoint, as you can just return a id_token and have the access token be NULL and that would satisfy the specification and Torsten could not complain that it was a violation. Seems like the token endpoint needs to be sorted out

From: Mike Jones
Sent: Tuesday, November 5, 2013 12:21 PM
To: Anthony Nadalin; Nat Sakimura
Cc: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: RE: [Openid-specs-ab] Issue #898: New Core - 1.2 Terminology - Authentication Request, Authorization Request (openid/connect)

Torsten's comment about the Token Endpoint was that he believes that it must always return an Access Token.  He wasn't objecting to it returning other things like Refresh Tokens, ID Tokens, etc.

Indeed RFC 6749 includes an example of it returning a non-standard field.

-- Mike
________________________________
From: Anthony Nadalin<mailto:tonynad at microsoft.com>
Sent: ‎11/‎5/‎2013 12:07 PM
To: Mike Jones<mailto:Michael.Jones at microsoft.com>; Nat Sakimura<mailto:sakimura at gmail.com>
Cc: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: RE: [Openid-specs-ab] Issue #898: New Core - 1.2 Terminology - Authentication Request, Authorization Request (openid/connect)
There is the issue of what an token endpoint should and should not return. It was clear from yesterdays Oauth discussions that people have different views, some people believe the openid returning an I'd token is not in the sprit of the Oauth specification

Sent from my Windows Phone
________________________________
From: Mike Jones<mailto:Michael.Jones at microsoft.com>
Sent: ‎11/‎5/‎2013 11:35 AM
To: Nat Sakimura<mailto:sakimura at gmail.com>
Cc: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] Issue #898: New Core - 1.2 Terminology - Authentication Request, Authorization Request (openid/connect)
The ID Token part is not part of the Authentication Request.  It’s contained in a response which is either an Authorization Response or Token Response, depending upon the flow used.  Therefore, I didn’t say anything about the ID Token in the Authentication Request definition.

We’re now talking about the ID Token in lots of introductory text, so I don’t think not saying anything about it in this definition a problem.

                                                            -- Mike

From: Nat Sakimura [mailto:sakimura at gmail.com]
Sent: Tuesday, November 05, 2013 1:36 AM
To: Mike Jones
Cc: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] Issue #898: New Core - 1.2 Terminology - Authentication Request, Authorization Request (openid/connect)

What about:

**Authentication Request**
Authorization Request used to obtain the result of authentication performed by the server as ID Token through the use of OpenID Connect extension parameters and profiled scopes

What is important about it is that the authentication is performed at the server and the result is transferred from the server to the client through ID Token.

2013/11/5 Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>>
I'm fine with adding the "Authorization Request" definition.  As for the Authentication Request definition, I have some quibbles with Nat's proposed language, because I find it to be less clear and somewhat circular.  Saying "to obtain the Authentication Result" doesn't add anything, and in fact, would just cause us to have to define "Authentication Result" as well.

How about something closer to this?

**Authentication Request**
An OAuth 2.0 Authorization Request using extension parameters and scopes defined by OpenID Connect to request that the End-User be authenticated by the Authorization Server, which is an OpenID Connect Provider.

                                -- Mike

-----Original Message-----
From: openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net> [mailto:openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>] On Behalf Of Nat Sakimura
Sent: Monday, November 04, 2013 11:13 PM
To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: [Openid-specs-ab] Issue #898: New Core - 1.2 Terminology - Authentication Request, Authorization Request (openid/connect)

New issue 898: New Core - 1.2 Terminology - Authentication Request, Authorization Requesthttps://bitbucket.org/openid/connect/issue/898/new-core-12-terminology-authentication

Nat Sakimura:

Capturing Breno's request on Nov. 4 that says: "I think we should have an explicit entry to Authorization Request that says: "An OAuth2 Authorization Request as defined in RFC 6749"
And then "Authentication Request" --> With a language more similar to the one proposed by Nat in this thread."

**Currently**:

**Authentication Request**
An OAuth 2.0 Authorization Request that requests that the End-User be authenticated by the Authorization Server.

**Proposed**:

**Authentication Request**
Authorization Request used to obtain the Authentication Result through the use of OpenID Connect extension parameters and profiled scopes

**Authorization Request**
OAuth 2 authorization request as defined in RFC 6749





_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto: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
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131105/66714153/attachment-0001.html>


More information about the Openid-specs-ab mailing list