The problem is that the artifact resolution request may not go to the same data-centre that the authentication was done at.
In principal if the artifact was a WRAP token signed by the IdP it could be exchanged for a full authentication token via a token server (STS). The pattern is well understood in WS-Fed, SAML and elsewhere. SAML breaks the flow up by separating the authentication query from a attribute query. WS-Fed uses a Secure Token Server (STS) to trade one token for another. The RP would still need to detect replay. It is not an unreasonable idea. The problem we are getting into is that people are building products based on a particular solution before forming the WG to discuss the spec. That will tend to influence the discussion. The downside of WRAP will be that the token/artifact may be larger. To meet the higher LoA the RP needs to use mutual TLS or sign the artifact resolution request. I strongly recommend against mutual TLS, that is what killed the SAML artifact binding. If there is an alternate idea for artifact binding it would need to be prototyped and submitted to the the V.next WG to stand a chance against what Nat is building. If the WG process had not broken down things would not be so far along in development. John B. On 2010-01-28, at 11:29 AM, Andrew Arnott wrote: > Forking thread... > > Hmm.... so my disclaimer here is that I haven't read Nat's spec on artifact > binding, so perhaps what I'm suggesting is almost the same thing as you've > already got... > > Allen had mentioned that artifact binding requires sharing state potentially > across data centers, which is difficult. And some have mentioned on this > and/or the general list (I forgot which) that Twitter's OAuth authentication > is sort of next-gen OpenID (which I've never understood). But I wonder... if > we're going with the artifact approach anyway, would using OAuth WRAP make > sense here? Consider... > > The RP/consumer sends the user to the IdP/OP/SP to authorize an OAuth WRAP > token, and the OP sends the user back to the RP with a small message. The RP > then requests the authorized token (I forgot the exact terminology here in > the WRAP spec) from the IdP, and uses that token to request authentication > status for the authorizing user, along with any attributes the RP needs. So > it's out of band, can result in a large response, or whatever. > > So far, I've not added any value to OpenID+artifact binding. > > Except that between the authorizing of the token and when the RP finally asks > for attributes, the IdP hasn't had to store any artifact or state of the > user, since the WRAP token is self-signed by the token issuer and contains > the information the RP is allowed to request. > > The OAuth WRAP token MAY still be valid. Even if for a very short time, it > would allow the RP to "replay" this token, possibly solving the problem of > the RP's return_to page being re-fetched (although probably not by itself > since the RP would still have to know not to re-authorize the token). But it > would also allow the RP to auto-log-off the user if the IdP began reporting > that the user was logged off. > > Just a thought. But it does seem that OpenID+artifact is a substantial > change from 2.0, so it's interesting to consider equally large change > alternatives that are already adopted just in case they make sense. There's > obviously a lot here that I haven't discussed or even considered, so feel > free to trash the idea. :) > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > > On Thu, Jan 28, 2010 at 3:02 AM, Nat Sakimura <[email protected]> wrote: > (2010/01/28 16:21), Allen Tom wrote: >> >> Hi all - >> >> Before I get started – I agree that in an ideal world, we’d have full end to >> end SSL, old browsers would be banned, and we’d POST data. >> >> However, requiring RPs to support SSL isn’t going to help adoption and is >> deal breaker for most applications that want to use OpenID today. >> Encouraging RPs to use SSL is a great idea – but it should not be required. >> >> Although most browsers can support URLs > 2KB, some proxy servers choke on >> URLs > 2KB. This is not fun to debug. > I add one more thing here: Many mobile browsers choke. >> >> In practice, enforcing the nonce only gives the illusion of additional >> security. If there’s a MITM, instead of replaying (or pre-playing) the >> assertion, the attacker will just steal the browser cookies instead. >> Assertions should have a limited lifetime – but this can be enforced by >> checking the timestamp and allowing for a narrow replay window. >> >> POST is technically the ideal solution, but results in a degraded UX. The >> proprietary market leaders have set the bar very high and we need to offer >> an open alternative that is just as good, if not better. We really aren’t >> going to get anywhere with a clunky UX. POST adds additional latency, and >> can cause strange warnings and a blank interstitial (the self submitting >> form). >> >> I really would like to be able to return an assertion using AX with a lot of >> attributes, and Hybrid that can fit within the 2KB limit. This is needed >> just to reach parity with the proprietary stuff. > Artifact Binding :-) Our implementation is returning (for the experiment > purpose) assertion that is well over 5MB with AX. > > =nat >> >> Allen >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> > > > -- > Nat Sakimura ([email protected]) > Nomura Research Institute, Ltd. > Tel:+81-3-6274-1412 Fax:+81-3-6274-1547 > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
