I thought you wanted to keep the profile endpoint (user_info) out of this. Once you have a user-info type endpoint you get into defining scopes for claims and I thought Tony wanted to avoid this and have it be only session authentication.
Connect publishes its idp config in the .well-known directory of "iss" that allows all the endpoints to be discovered. Over time the Authorization endpoint URI will change and will contain query parameters etc. tying iss to a logical name like a SAML entityID that could provide the other endpoint information was a more familiar pattern to people. In some ways Connect duplicates one of the entity-id to meta-data discovery methods in SAML meta-data that never got traction (other than perhaps in ADFS). John B. On 2013-08-27, at 7:37 PM, Phil Hunt <phil.h...@oracle.com> wrote: > See below. > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > On 2013-08-27, at 4:27 PM, John Bradley <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> 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 >>> phil.h...@oracle.com >>> >>> >>> Begin forwarded message: >>> >>>> From: 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>, Anthony Nadalin >>>> <tony...@microsoft.com>, Tony Nadalin <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. >>>> >>>> The IETF Secretariat >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
