Minor typo is in section 2,
"The Authentication Code Grant type is used in exactly the same manor
as the Authorization Code Grant Section 4.1 [RFC6749] and has the
same features and conditions. The *Authorization* Code Grant
extends..."
Cheers, Sergey
On 28/08/13 00:37, Phil Hunt wrote:
See below.
Phil
@independentid
www.independentid.com <http://www.independentid.com>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On 2013-08-27, at 4:27 PM, John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> wrote:
It is better. We need to talk about what you have done with "min_alv"
vs "acr" from connect which is extensible via a IANA registry of
Authentication contexts.
If it came down to reserving the strings 1 2 3 4 for the ISO29115
reference that could probably be arranged.
I don't know that throwing an error if the min can't be supported is
the correct thing. We had a lot of debate about that and decided that
returning the actual acr and letting the client decide was better than
an error.
[PH[ I agree.
Also remember that the request is not signed so someone could modify
it to remove min_alv and spoof a RP that expects all positive results
to meet what it asked for.
More discussion on min_alv is required.
[PH] Yes. Returning what actually was done without an error is a better
approach.
Also, just noticed that the "hint" parameter should be "login_hint".
I think we also need to discuss how the client detects the profile API
type and whether the AS can return multiple endpoints (and is that even
a good thing). A structured attribute giving endpoint type and URL
might be the way to go.
John B.
On 2013-08-27, at 12:52 PM, Phil Hunt <phil.h...@oracle.com
<mailto:phil.h...@oracle.com>> wrote:
FYI. Based on feedback from Berlin, Tony and I have revised the
draft to include:
* Alignment with OpenID Connect (using id_token)
* Always returns a JWT
* Minimum assertion level on request
* Return information about the type of authentication performed
Thanks for your input.
Phil
@independentid
www.independentid.com <http://www.independentid.com/>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
Begin forwarded message:
*From: *internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
*Subject: **New Version Notification for
draft-hunt-oauth-v2-user-a4c-01.txt*
*Date: *27 August, 2013 8:56:45 AM PDT
*To: *Phil Hunt <phil.h...@yahoo.com <mailto:phil.h...@yahoo.com>>,
Anthony Nadalin <tony...@microsoft.com
<mailto:tony...@microsoft.com>>, Tony Nadalin <tony...@microsoft.com
<mailto:tony...@microsoft.com>>
A new version of I-D, draft-hunt-oauth-v2-user-a4c-01.txt
has been successfully submitted by Phil Hunt and posted to the
IETF repository.
Filename:draft-hunt-oauth-v2-user-a4c
Revision:01
Title:OAuth 2.0 User Authentication and Consent For Clients
Creation date:2013-08-27
Group:Individual Submission
Number of pages: 10
URL:
http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-01.txt
Status: http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c
Htmlized: http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-01
Diff: http://www.ietf.org/rfcdiff?url2=draft-hunt-oauth-v2-user-a4c-01
Abstract:
This specification defines a new OAuth2 endpoint that enables user
authentication session and consent information to be shared with
client applications.
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org
<http://tools.ietf.org/>.
The IETF Secretariat
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
