Torsten, Yes. Federation is the basis for proposal. Federated social interactions.
The value is that the provider is able to verify the assertion that user dbounds on host cliqset.com has requested access token which it will use to access and/or request access to protected resources within the google.com realm, such as remote friending/following. The provider does not need to, or necessarily want to authenticate the remote user. It merely needs to verify the assertion in order to confirm the origin user/host. References: http://status.net/2010/07/13/what-is-the-federated-social-web http://status.net/2010/07/14/features-of-a-federated-social-web -- darren bounds dar...@cliqset.com On Thu, Jul 29, 2010 at 4:47 PM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > So what the value of that assertion? The authz server cannot authenticate > the user (probably not even identify). Or do you assume some kind of > federation between the two domains? > > Am 29.07.2010 20:36, schrieb Darren Bounds: >> >> Yes, but with no requirement that the user have an account on the >> provider. It is merely an assertion the UserA on HostX made the >> request. >> >> On Thu, Jul 29, 2010 at 1:05 PM, Torsten Lodderstedt >> <tors...@lodderstedt.net> wrote: >> >>> >>> So this assertion is conceptually equivalent to a case where the client >>> would have sent username and password of dbounds at the authz server. Is >>> this correct? >>> >>> Am 29.07.2010 17:32, schrieb Darren Bounds: >>> >>>> >>>> Torsten, >>>> >>>> The URI represents an end-user at a domain. Through this assertion the >>>> provider is able to verify the magic signature and thus confirm user >>>> dbounds at host cliqset.com has requested an access token. >>>> >>>> References: >>>> http://code.google.com/p/webfinger/wiki/WebFingerProtocol >>>> >>>> >>>> http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00.html >>>> >>>> >>>> http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html >>>> >>>> On Thu, Jul 29, 2010 at 2:40 AM, Torsten Lodderstedt >>>> <tors...@lodderstedt.net> wrote: >>>> >>>> >>>>> >>>>> Darren, >>>>> >>>>> I have got some questions regarding your posting, esp. the assertion. >>>>> >>>>> >>>>>> >>>>>> 1) cliqset.com would like to request an access token from google.com. >>>>>> Sends a request with grant_type=assertion. >>>>>> >>>>>> Request: >>>>>> POST /token HTTP/1.1 >>>>>> Host: google.com >>>>>> Content-Type: application/x-www-form-urlencoded >>>>>> >>>>>> grant_type=assertion&assertion_type=http://webfinger.org/&; >>>>>> >>>>>> >>>>>> >>>>>> assertion=eyJ1cmkiOiAiYWNjdDpkYm91bmRzQGNsaXFzZXQuY29tIiwibWFnaWNfc2lnbmF0dXJlIjogImFzZGxra2xhZnNkamtsZHNmamxraj0ifQ== >>>>>> >>>>>> The assertion value in the request is a Base64 encoded JSON string >>>>>> with two properties, uri and magic_signature. Example: >>>>>> >>>>>> { >>>>>> "uri": "acct:dbou...@cliqset.com", >>>>>> "magic_signature": "asdlkklafsdjkldsfjlkj=" >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> What is the meaning of the assertion? Does the uri represent an >>>>> end-user >>>>> or >>>>> the client? >>>>> How does the assertion represent an authorization, given that you try >>>>> to >>>>> make end-user authorization via browser redirect an optional step. >>>>> >>>>> regards, >>>>> Torsten, >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
