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: openid-specs-ab-boun...@lists.openid.net > [mailto:openid-specs-ab-boun...@lists.openid.net] On Behalf Of sa...@zxidp.org > Sent: Tuesday, October 26, 2010 6:40 PM > To: Mike Jones > Cc: sa...@zxidp.org; openid-specs...@lists.openid.net; oauth@ietf.org; > openid-specs-conn...@lists.openid.net > 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 <michael.jo...@microsoft.com> 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 j...@example.com, 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 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > Openid-specs-ab mailing list > openid-specs...@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab > > _______________________________________________ > openid-specs-connect mailing list > openid-specs-conn...@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-connect
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
