I am agreeing using oAuth in that way is a good idea. It has been discussed various places. I think Eve's UMA group is looking at some options for that.
You could however do the same thing with WebFinger/XRD. It would have been better to have worked on this together over the last year and a half. However we are where we are and we need to look at it as a legitimate proposal. However it will be up against other similar work in the community. John B. On 2010-10-29, at 12:57 PM, Anthony Nadalin wrote: > I would not say that this is just a JSON version of XRD, as XRD has quite a > few more complex feature. What is being suggested here is being able to use > OAuth for the authorization/delegation to discovery information in a very > simple chunkable forward means. > > -----Original Message----- > From: John Bradley [mailto:[email protected]] > Sent: Thursday, October 28, 2010 5:22 PM > To: Anthony Nadalin > Cc: the Connect work group; [email protected]; > [email protected]; [email protected] > Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery > > If there is no authorization mechanism, then this is just a JSON version of > XRD. > > Not that you couldn't add authorization to XRD. > > We were planning on doing that as an option for a proxy resolution flow that > would look quite similar. > > The way that the existing XRI resolver works is quite similar to what you > describe filtering by service. > One of the use cases has been adding authentication, but there was never > enough interest. > > Too bad MS didn't participate in XRD. > > John B. > On 2010-10-28, at 8:42 PM, Anthony Nadalin wrote: > >> So not sure that this would be handled by the SWD itself but as pointed out >> in the SWD specification is that the SWD may be accompanied by an >> authorization header and this is where I would expect that to happen >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of John >> Bradley >> Sent: Thursday, October 28, 2010 8:41 AM >> To: the Connect work group >> Cc: [email protected]; [email protected]; [email protected] >> Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery >> >> In the case where the user logs in to a RP with a PPID type identifier. >> >> How could the person then allow the RP to discover their service endpoints. >> Also conversely would publishing the endpoint provide a way for the RP to >> correlate the user without permission. >> >> One common practice for openID PPID is that the IdP generates the PPID via >> AES128(actual ID + RP or sector identifier). >> >> In that case the RP could do an oauth flow to the IdP discovery endpoint to >> get permission to see the user endpoints. >> The IdP could decrypt the opaque identifier to determine the actual subject. >> >> That would protect the non correlation unless the user decides to permit >> discovery. >> >> The model if not the details seem similar to some work that is being >> submitted to the ITU-T as I understand it. >> >> John B. >> >> >> On 2010-10-28, at 12:07 PM, Anthony Nadalin wrote: >> >>> Sampo, can you give a usecase of how you would use the pairwise >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of >>> [email protected] >>> Sent: Tuesday, October 26, 2010 6:40 PM >>> To: Mike Jones >>> Cc: [email protected]; [email protected]; [email protected]; >>> [email protected] >>> Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery >>> >>> Simple enough spec. I like the notion of service type. However some >>> questions to answer: >>> >>> How would one convey saml2:Assertion as the "principal"? Or how would one >>> convey a saml2:NameID as the "principal"? >>> >>> Or in more generic sense, how would one convey a pairwise pseudonym as >>> principal? >>> >>> Cheers, >>> --Sampo >>> >>> Mike Jones <[email protected]> said: >>>> Having a simple discovery method for services and resources is key to >>>> enabling many Internet scenarios that require interactions among parties >>>> that do not have pre-established relationships. For instance, if Joe, >>>> with e-mail address [email protected], wants to share his calendar with >>>> Mary, then Mary's calendar service, in the general case, will need to >>>> discover the location of Joe's calendar service. For example, Mary's >>>> calendar service might discover that Joe's calendar service is located at >>>> http://calendars.proseware.com/calendar/joseph by doing discovery for a >>>> service named urn:adatum.com:calendar at example.com for the account joe. >>>> >>>> Yaron Goland<http://www.goland.org/> and I are submitting this Simple Web >>>> Discovery >>>> (SWD)<http://self-issued.info/docs/draft-jones-simple-web-discovery-00.html> >>>> draft (attached and at >>>> http://self-issued.info/docs/draft-jones-simple-web-discovery-00.html) for >>>> consideration by the community to address this need. SWD is simple to >>>> understand and implement, enables different permissions to be applied to >>>> discovery of different services, and is JSON-based. I look forward to >>>> discussing this with many of you next week at >>>> IIW<http://www.internetidentityworkshop.com/iiwxi-11-in-mountain-view/>. >>>> >>>> -- >>>> Mike >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> Openid-specs-ab mailing list >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-specs-ab >>> >>> _______________________________________________ >>> openid-specs-connect mailing list >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-specs-connect >> >> _______________________________________________ >> Openid-specs-ab mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs-ab > > _______________________________________________ > openid-specs-connect mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs-connect
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
