I'm concerned that the current "alv" and "min_alv" text wouldn't survive IESG 
review since depending up NIST SP-800-63-2 is US-centric.  The point of OpenID 
Connect "acr" (authentication context class reference) claim using RFC6711 is 
that the authentication context values used are internationalized.

I agree that using the strings "1", "2", "3", and "4" to refer to the ISO 29115 
authentication level values would be preferable to the current "alv" text, 
since that approach is much more likely to survive IESG review and result in an 
approved RFC.  I'd therefore suggest making this change sooner rather than 
later.

                                                                -- Mike

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil 
Hunt
Sent: Tuesday, August 27, 2013 4:37 PM
To: John Bradley
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for 
draft-hunt-oauth-v2-user-a4c-01.txt

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/listinfo/oauth

Reply via email to