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>
[email protected] <mailto:[email protected]>
On 2013-08-27, at 4:27 PM, John Bradley <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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/>
[email protected] <mailto:[email protected]>
Begin forwarded message:
*From: *[email protected] <mailto:[email protected]>
*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 <[email protected] <mailto:[email protected]>>,
Anthony Nadalin <[email protected]
<mailto:[email protected]>>, Tony Nadalin <[email protected]
<mailto:[email protected]>>
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listi
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
