<br><div><span class="gmail_quote">On 8/31/07, <b class="gmail_sendername">James Henstridge</b> <<a href="mailto:james@jamesh.id.au">james@jamesh.id.au</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>You still want the user involved in the granting of an authentication<br>token though, right? Trying to replace the "UA" in the authentication<br>workflow is quite a big change, and limits what the OP can do.
</blockquote><div><br>Yes, granting the secret must be done using the traditional User Agent, as the user must be logged in using their normal credentials in order for the OP to deliver the secret to the requesting RP.<br>
<br>Considering it's an Extension, this isn't really any sort of change that limits what the OP can do. It simply codes a standard credential format that is only used for when a site wishes to log into another site using a specific OpenID.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">With your proposal, the user's OP needs to implement an extension.<br>This brings up a few questions:
<br><br>1. Should the data provider only let users register if their OP<br>implements the extension? What is the benefit to the data provider in<br>enforcing such an extension?</blockquote><div><br>Trusted Authentication doesn't require the destination site (the DP) to implement any changes at all. One would hope that the DP is offering some valuable service other than just providing data to client sites.
<br><br>As for the client site, yes, functionality will be lost if the OP doesn't support the extension that would allow them to log in to another site. If the extension becomes popular, it would be in the best interest of the OP to implement the extension if they wanted to keep users from switching to a different provider that does support the extension.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2. If only some users' OPs implement the extension, can the data<br>consumer rely on the protocol at all?
</blockquote><div><br>Why not? They would be able to support this, and if the OP doesn't support the extension, they can continue using those very insecure "API key" implementations that are being used today. Or, they can even suggest that the user switch to a supporting provider.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">In contrast, both the data provider and consumer have an incentive to<br>implement an extension for auth token transfer, so a spec that only
<br>requires modifications to those parties seems easier to roll out.<br>What do you think? <br></blockquote><br>Well, as above, no changes are needed at the DP. I think it would be much easier to simply modify the hand-full of OPs and the Client RPs that want to support the spec, which is expected with any OpenID extension.
<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">[snip]<br>> to log on to the destination site to invalidate the token. What if the user
<br>> has 50 of these API connections set up? That's 50 sites to visit in order<br>> to manage these tokens.<br><br>I guess that is a concern. But how often do you expect the data<br>provider to check the user's OP to see if the token is still valid?
<br>If it doesn't check often, then revoking the token at the OP level<br>might take a while to take effect.</blockquote><div><br>Well, it really is up to the DP to determine how long it wants its sessions open, just with any other website. For instance, banks will automatically expire the session if there is no activity for 15 minutes. In this case, the DP will simply force the Client RP to authenticate again with the OP.
<br></div></div><br>As stated in the spec, it's not my intention to mandate how user data (and the data session) is managed between the client RP and the DP.<br><br>Your feedback is always welcome.<br><br>Thanks,<br><br>
John <br>