John, I do not what to do anything to specify the profile endpoint. The big problem is there are already many APIs -- user_info is but one.
The problems in the IETF OAuth space, is that the URL the client "thinks" is the authenticated user is not guaranteed to be the user. For example, the clients assume "facebook.com/me" is the authenticated user -- and in that case it is. But for other APIs there are no aliases. For example, my client could be requesting information about your Facebook endpoint and because I am a friend, the client thinks it just authenticated you. The point of returning the profile url is to ensure that the client knows what the authenticated user's profile URL is. I raised the question of whether returning multiple URLs is useful since many cloud providers are actually offering multiple APIs for the same user information. My feeling is that that client already knows what it wants and is merely checking that the value matches its expectations. I think the .well-known might be useful, but since this may change on a user-by-user basis, it is problematic. For example, the authenticated user may be federated. What then? Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-08-27, at 4:51 PM, John Bradley <ve7...@ve7jtb.com> wrote: > 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 >>> >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
