RE: Non-interactive logins
This looks like an interesting proposal. A 'black box' with regards to how the application obtains assoc_handle and signature from the OP remains, but it looks like a step in the right direction. What remains to be done to elevate this proposal this to standard? ons, 16 07 2008 kl. 15:09 +1000, skrev Manger, James H: Hi Anders, There has been some work on this important issue, though it seems to have been dormant for a while. There seem to be two proposals (by Martin Atkins) using OpenID as an HTTP authentication mechanism. It is suitable for non-browser, non-interactive use cases. http://wiki.openid.net/OpenIDHTTPAuth http://wiki.openid.net/OpenID_HTTP_Authentication I really like the idea of this basic flow: 1. RP indicates it supports OpenID with WWW-Authenticate: OpenID header; 2. App interacts with the app's OP; 2. App sends OpenID authentication response to RP in Authorization header; 3. RP performs discovery; 4. RP does direct verification with OP. App --GET xxx-- RP --401 WWW-Authenticate: OpenID realm=...-- App OP [if necessary] App --GET xxx Authorization: OpenID opened-auth-request-stuff-- RP RP --GET claimed_id-- --discovery XRDS/HTML-- RP --POST ...openid.mode=check_authentication-- OP --is_valid=true-- App --200 content-- ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Non-interactive logins
Let me elaborate on the idea and requirements I have in mind. The use case I'm thinking of is perhaps not so much non-interactivity in particular as it is login with no black boxes. Currently, the RP is supposed to delegate full control of the login process to the URL where the OP redirects the user. This is impractical in cases where you can't readily produce a browser window for the user, e.g. at the desktop login screen or in embedded systems. In these cases, it would be better if there was a standard non-browser way to authenticate the user. OAuth still requires the user to approve each access token somehow, typically by browser. If you are standing at the desktop login at the only computer in a public library, and don't have a browser phone or similar, it is unlikely that you'll be able to make such an approval. Furthermore, the library computer have little use of the access token once you're done using the computer. Again, OAuth appears to me to concern authorized machine _access_ to a particular resource while I'm asking for machine _authentication_, which belongs in the realm of OpenID. -- Anders Feder [EMAIL PROTECTED] ons, 16 07 2008 kl. 13:26 +0800, skrev James Henstridge: On Wed, Jul 16, 2008 at 12:38 PM, Anders Feder [EMAIL PROTECTED] wrote: tir, 15 07 2008 kl. 21:28 -0700, skrev John Panzer: And of course any number of extensions could be created to obtain an access token via an alternate path, after which normal OAuth can be used. Sure, but isn't this equally true for OpenID? Most OpenID RPs maintain some kind of session for the user, but that is not required by the spec (some require OpenID auth to perform each action). In contrast, the whole point of OAuth is to generate an authorisation token that can be used for machine access to a site multiple times in the future. The OAuth service provider might use OpenID when deciding whether to grant an authorisation token to a client to access the site on behalf of a particular user if appropriate. James. -- Anders Feder [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Non-interactive logins
Hello, There have been some discussion over the years about using OpenID for non-interactive logins. Can someone kindly tell me what the status is of this feature? In particular login from non-browser applications - is this currently possible (e.g. using client certificate authentication)? Thanks. -- Anders Feder [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Non-interactive logins
If I'm not mistaken, OAuth requires the user to approve the authentication request in her browser, which is an interactive action. Joseph Holsten pointed me to Appendix A of the OAuth specification for an example. In step A.3, The Consumer redirects Jane’s browser to the Service Provider User Authorization URL to obtain Jane’s approval for accessing her private photos. Also, OAuth appears to be more about authorization (to access a remote resource) than about authentication. Is there any way to operate either OpenID or OAuth entirely non-interactively? tir, 15 07 2008 kl. 08:38 -0700, skrev Scott Kveton: Hi Anders, You might want to check out OAuth ... it was developed for just such a situation. - Scott On Tue, Jul 15, 2008 at 4:20 AM, Anders Feder [EMAIL PROTECTED] wrote: Hello, There have been some discussion over the years about using OpenID for non-interactive logins. Can someone kindly tell me what the status is of this feature? In particular login from non-browser applications - is this currently possible (e.g. using client certificate authentication)? Thanks. -- Anders Feder [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Non-interactive logins
tir, 15 07 2008 kl. 21:28 -0700, skrev John Panzer: And of course any number of extensions could be created to obtain an access token via an alternate path, after which normal OAuth can be used. Sure, but isn't this equally true for OpenID? If that is the case, I would like to ask the list if anybody is interested in working towards such an extension. Joseph Holsten pointed me to Appendix A of the OAuth specification for an example. In step A.3, The Consumer redirects Jane’s browser to the Service Provider User Authorization URL to obtain Jane’s approval for accessing her private photos. Also, OAuth appears to be more about authorization (to access a remote resource) than about authentication. Is there any way to operate either OpenID or OAuth entirely non-interactively? tir, 15 07 2008 kl. 08:38 -0700, skrev Scott Kveton: Hi Anders, You might want to check out OAuth ... it was developed for just such a situation. - Scott On Tue, Jul 15, 2008 at 4:20 AM, Anders Feder [EMAIL PROTECTED] wrote: Hello, There have been some discussion over the years about using OpenID for non-interactive logins. Can someone kindly tell me what the status is of this feature? In particular login from non-browser applications - is this currently possible (e.g. using client certificate authentication)? Thanks. -- Anders Feder [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Anders Feder [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Johnny Bufu wrote: This is basically a push approach, as opposed to the pull approach you were suggesting. I'm new to OpenID, and no engineer, but I have to say that I have a bad feeling about this 'push' approach. It inverts the relationship between client and server and seems entirely contrary to the stateless spirit of the Web: * The RP can't know the status of the information it is working with - it just have to assume that the attributes it has in store are up-to-date. * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. * When updating, the OP impose a previous address structure upon the Web, regardless of how it is actually organized now. * While the RP's requests the information, the OP is made responsible for doing the work associated with distributing it. * The OP must donate storage space to support the distribution of information to RP's it has no direct interest in. A malicious RP may even exploit this storage space for own purposes. * Attributes are not easily referenced to, say, sub-contractors of an RP. The model impose limits upon the complexity of the services that may be derived from it. Regards, Anders Feder ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Rowan, Thanks for your response. Again, I have no formal education, so don't bother if my comments are worthless. I just want to specify the concerns I do have, based on my own experience, in case they are of any use to the process. Rowan Kerr skrev: The RP can send an update_url to the OP when it fetches the attributes, so it will get new values when the user changes them at the OP. But the RP can't know if the update_url is honored, i.e. if it will ever receive any updates from the OP. Imagine an RP requesting your bank account number X from your OP. Time goes by, and your OP goes out of business. Later, you switch banks and your account number X is assigned to someone else. In the meantime, the RP has been preparing a payment for a job you have done for them. The RP look up your account number in its database, and see X. And since the RP has not received any updates to your bank account information, it reasons that your account number is still X and consequently disburse your payment on a stranger's account ... One could say that OpenID should not be relied on to exchange sensitive information like bank account numbers, but 1) I think its a shame to limit a technology with such great potential, and 2) chances are that OpenID will be relied upon anyway - the sensitive transactions will just be performed longer down the chain, where they can't be checked. * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. Fails when? On a Store request? Yes, or if the Store request never leaves the OP server, for whatever reason. Not sure I understand this. OP's normally would not have interest in any particular RPs the User has interest in RPs :) Although it is up to the individual OP to set rules about who it wants to talk to. User interest in RP's come and go, but this is not reflected in the OP's database. After a couple of years use, each user is likely to have some thousands of RP entries associated with their identity in the OP's database, while the user may only have active interest in a fraction of these. You're free to publish the RDF for the attributes you support... then they are reference-able aren't they? My point was that attributes does not have a canonical identifier that can be passed on to someone else who might put the attribute to better use. As far as I can see, the wheel more or less has to be reinvented each time someone wish to exchange attribute references (unless someone outside OpenID standardize the exchange process). Regards, Anders Feder ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Dick Hardt wrote: There are two common client server design patterns. Request / Response and Publish / Subscribe. I see - I was not aware that the latter model was so well-understood in the client/server paradigm. The RP has what ever the user last gave the RP. If the user is involved in the transaction, the RP may ask the user for up to date information. Note that your concern is constrained to situations where the user is not involved. It is, but will automated transactions not make up a significant portion of the communications on the service-oriented Web? * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. When the data changes, the user then decides if the RP gets the data. If the user did not want the RP to get, well that is what the user decided. This is user centric after all. I see the merits of user-centricism, but what happens if a user do want an RP to receive an update but the RP is unavailable? For instance, imagine I have ordered a secret product from an RP. Before my order is fully processed, circumstances force me to move to another (postal mail) address. If the connection to the RP is not available when updating my mail address attribute on the OP, for whatever reason, the RP will send the secret package to my old address and whoever lives there now. * When updating, the OP impose a previous address structure upon the Web, regardless of how it is actually organized now. The converse would be the RP imposes an address structure on the OP on where to get the updated data. And rightfully so, because the user selects his OP based on his trust that its address structure will not change - this is the key principle in OpenID. Well, the OP would be responsible for responding to all the myriad useless RP requests for updated data if a pull model. Good point :) In most cases you are probably right, but one can imagine attributes, especially in futuristic scenarios, which are almost inherently 'pull' (like GPS data) such that translating them into 'pushes' are immensely ineffective. But I guess 'push' is per-attribute optional, in that case? information to RP's it has no direct interest in. A malicious RP may even exploit this storage space for own purposes. * The OP must donate storage space to support the distribution of The alternative would be the OP would need to donate storage to support which RPs are allowed to ask for data. Only if the user actually wish to restrict access - and the RP would not have access to this storage. Anyway, I'm convinced you have thought it through. Pull relates to push as quantum mechanics relates to relativistic physics - but very often quantum mechanics is overkill. Regards, Anders Feder ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Wayne Pierce wrote: When I update my information at a new OP how about some way to tell the RP it is the most authoritative. Not sure if this should be taken care of at the application or protocol level, I'd like to see it in the protocol though. The big concern I see with this is that anyone could setup an OP and claim to be the most authoritative source of information. I agree completely. Currently, if my OP turns rogue or otherwise fail to serve me, I'm left with no recourse. A bullet-proof way of dealing with this would be with digital signatures though I sense some aversion to PKI in the OpenID community. The OP could tell the user if there was a failure. This way the user can notify the RP or at least be aware of the problem. Not perfect, but it could be treated just like a bounced email or DNS update failure. Yes, this is probably how it will be handled and it will work. I just think there will be corner cases where the user is not able to 'change course' in time. And handling corner cases sets excellent technology apart from very good technology - but it will work. Regards, Anders Feder ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
