The authenticated user is the "sub" scoped to "iss" not the profile URL. A profile URL is informational and may change for the user. I think making it a structured element describing the API is going beyond the "Simple"
I was assuming that the profile URI would be under the control of the AS/Issuer and there would be one endpoint per AS like Connect which has a single .well-known for the issuer. Per user discovery uses webfinger to point to public info. now that webfinger is a RFC you could return the users acct: URI for webfinger do the client can get public info. If you want to specify arbitrary protected resources as the profile URI then you are opening a big can of complexity that Connect saves for the Advanced profile with distributed claims, not something you want in the simple profile. You want to avoid the RP using profile url or email as the identifier for the subject. Connect defines its subject tightly in that it must be A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., "24400320" or "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4". It MUST NOT exceed 255 ASCII characters in length. The value is a case sensitive string. Keeping PII out of the subject also saves a lot of grief, and numbers don't have the same pressure for reassignment as other nicknames. John B. On 2013-08-27, at 8:28 PM, Phil Hunt <[email protected]> wrote: > 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 > [email protected] > > > > > > > > On 2013-08-27, at 4:51 PM, John Bradley <[email protected]> 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 <[email protected]> wrote: >> >>> See below. >>> Phil >>> >>> @independentid >>> www.independentid.com >>> [email protected] >>> >>> >>> >>> On 2013-08-27, at 4:27 PM, John Bradley <[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]> 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 >>>>> [email protected] >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: [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]>, Anthony Nadalin >>>>>> <[email protected]>, Tony Nadalin <[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. >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
