Hi. Inline:
On Fri, Aug 21, 2009 at 10:07 PM, John Bradley<[email protected]> wrote: > I am not saying that it can't or shouldn't be done this way. > > Only that we do need to be mindful that the potential impact on larger OP > may not be proportionate. It is probably related to the performance of key-value store. > > If this becomes the default binding for 2.1 as you propose, that is an > important consideration for adoption. Indeed. Large provider's feedback is essential on this. > > I don't know that oAuth is completely equivalent regarding timing and token > use. Initial direct POST == OAuth:Request Token Request (6.1.1) Response(Artifact) == OAuth:Unauthroized Request Token (6.1.2) Indirect Auth Request with Artifact == OAuth:User Authorization (6.2) Direct GET assertion == OAuth:Obtaining an Access Token (6.3) > > It is a however a close analogy, I will think about it. > > John B. > On 20-Aug-09, at 10:53 PM, =nat wrote: > >> >> To be exact, it is one direct POST, one indirect GET, then one direct GET >> all from RP->OP. >> It is the same as OAuth so I believe it can be done at a large OP such as >> Google/Yahoo! etc. >> >> =nat >> http://www.sakimura.org/en/ >> http://twitter.com/_nat >> >> On Thu, 20 Aug 2009 21:14:39 -0500, John Bradley <[email protected]> >> wrote: >>> >>> Breno, >>> >>> It could be RESTful but Nat's current proposal involves the OP >>> synchronizing two information from two GET requests from different >>> clients in near real time. >>> >>> For a small OP with a single server that is probably not a significant >>> problem. >>> >>> As openID is extensible I am not certain that trying to come up with a >>> more compact encoding will suffice for Nat. >>> >>> John B. >>> >>> On 20-Aug-09, at 1:14 AM, Breno de Medeiros wrote: >>> >>>> Hi John, >>>> >>>> I think this could be implemented in a RESTful way. >>>> >>>> For instance, an OP could create a really compressed scheme to >>>> represent the payload initially sent by the RP. For instance, if an OP >>>> supports email address, birthday, and zip code, and the RP has >>>> requested all of them, you could make the artifact be: ax-e_bd_zip >>>> >>>> In other words, there is no need why an artifact cannot be constant >>>> for a particular set of attributes. If the user does not approve all >>>> of them, the OP could return a different artifact in the response >>>> (there should be the assumption that the artifacts are distinct, and >>>> the OP endpoint to redeem the artifact should be part of the >>>> response). >>>> >>>> >>>> On Wed, Aug 19, 2009 at 7:02 PM, Nat Sakimura<[email protected]> >>>> wrote: >>>>> >>>>> John, >>>>> >>>>> On Thu, Aug 20, 2009 at 10:11 AM, John Bradley <[email protected] >>> >>>>>> >>>>> wrote: >>>>>> >>>>>> Nat, >>>>>> >>>>>> You don't have the new Sec 9.4 hi-lighted like the other changes >>>>>> so I >>>>>> missed it. >>>>> >>>>> Sorry, I fixed it. >>>>> >>>>>> >>>>>> Lets see if I follow this now. >>>>>> >>>>>> The RP sends a direct request openid.mode=art_res to the OP (9.4) >>>>>> with >>>>>> AX, PAPE parameters and the OP provides a (10.3) Artifact response. >>>>>> >>>>>> The RP then makes a indirect request with openid.artifact set to >>>>>> the value >>>>>> obtained from the artifact response. >>>>>> >>>>>> The OP then looks up the request based on the artifact. >>>>>> (conflicting >>>>>> parameters are resolved in some way) >>>>> >>>>> Direct request should take precedence. >>>>> >>>>>> >>>>>> The User authenticates (must happen after the artifact is looked >>>>>> up or you >>>>>> need to include PAPE in the indirect request) >>>>> >>>>> MUST happen after the artifact look up as the claimed id is in it. >>>>> >>>>>> >>>>>> The user consents to releasing attributes. >>>>>> >>>>>> The OP returns a positive assertion with openid.artifact in the >>>>>> response >>>>>> (you need to include that in 10.1) >>>>> >>>>> Sequence-wise, the OP does not return a positive assertion here but >>>>> it >>>>> returns an Artifact Response (10.3). >>>>> Positive assertion is returned later. >>>>> I am not sure if openid.artifact is needed in the positive >>>>> assertion since >>>>> it is returned as the response to the assertion request as >>>>> openid.artifact >>>>> as one of the request parameter. >>>>> >>>>>> >>>>>> The RP then makes another direct request openid.mode=assertion_req >>>>>> openid.artifact={artifact} >>>>>> >>>>>> The OP then returns the assertion with the extension payload. >>>>> >>>>> Yes. It returns the auth and extension payload including claimed >>>>> identifier >>>>> etc. >>>>>> >>>>>> Am I getting close to what you are thinking? >>>>> >>>>> Quite. >>>>> >>>>>> >>>>>> I don't think we should underestimate the synchronization issues >>>>>> that a OP >>>>>> will have across a cluster with this. >>>>> >>>>> I agree. We need to be clever on how artifact should be hashed and >>>>> stored. >>>>> e.g., store (artifact,payload) pair on distributed storage in such >>>>> a way >>>>> that you can locate the location from artifact (e.g., if the >>>>> Artifact is an >>>>> URL, it is trivial). >>>>> FYI, in CX, I have made the artifact created by the RP so that RP >>>>> to OP >>>>> request is always with the Artifact, so that a load balancer can >>>>> land the >>>>> request to the same server. Perhaps that's a better way but has a >>>>> side >>>>> effect that the indirect request gets bigger. >>>>> >>>>>> >>>>>> We would be bending the principals of REST with this. I would >>>>>> like to >>>>>> get the opinion of some of the larger OPs on this. >>>>> >>>>> I am not so sure about it (bending REST). >>>>> Think of it like this: >>>>> The authentication request over direct communication is stored on >>>>> the server >>>>> side (the OP) as a resource and the OP returns a Resource URI, >>>>> which is >>>>> called "Artifact". >>>>> The RP makes a GET request to a resource uri constructed from the >>>>> OP End >>>>> Point URI and the Artifact. >>>>> Is this bending REST? >>>>> >>>>>> >>>>>> The two requests coming from different IP will likely wind up on >>>>>> different >>>>>> servers. >>>>> >>>>> Yes, but in principle, it should not be a problem. >>>>> >>>>>> >>>>>> This on it's own makes data snooping worse not better. >>>>> >>>>> I do not get it. Could you explain more? >>>>> >>>>>> >>>>>> We need mutual TLS for the direct connection where the OP verifies >>>>>> the >>>>>> return_to URI against the cert of the incoming connection. >>>>>> >>>>>> Unless the claimed_id is only passed in the direct session it >>>>>> probably >>>>>> would not meet the no snooping requirement. I need to consult on >>>>>> that. >>>>> >>>>> The claimed_id is only passed in the direct session. In the Artifact >>>>> binding, it is only the Artifact and signature that are sent through >>>>> indirect communication. >>>>> >>>>>> >>>>>> Without mutual TLS the artifact in the indirect response needs to be >>>>>> encrypted. >>>>> >>>>> Does it have to be mutual TLS? Of course, it is better that way, >>>>> but I do >>>>> not want to raise the bar too much. >>>>>> >>>>>> >>>>>> I am traditional and still prefer to encrypt the returned token >>>>>> with the >>>>>> cert you get from RP discovery to verify the return_to. >>>>> >>>>> Are you talking about the Artifact or the Data? >>>>> For Data, yes, I do, too. >>>>> I was also going to encrypt the Artifact, but SAML was not doing >>>>> that so I >>>>> left it unencrypted. >>>>>> >>>>>> >>>>>> Your proposal is simple in some ways but I don't know that it >>>>>> meets all of >>>>>> the potential use cases. >>>>> >>>>> Without the list of use cases, it is difficult to estimate :-) >>>>> My primary use case is mobile. I think it satisfies it. For more >>>>> security >>>>> oriented things, you can use something like CX ;-) Of course, that >>>>> requires >>>>> more complexity, namely, the public key discovery, payload digital >>>>> signature, payload encryption, etc. >>>>> >>>>>> >>>>>> If we are going to dig into this I don't know that doing it >>>>>> outside of WG >>>>>> IPR coverage. >>>>> >>>>> You are right. Since CX covers artifact in its scope, it might be >>>>> good >>>>> discussing it under CX WG IPR. In parallel, we can spin up Authn >>>>> 2.1 WG and >>>>> move the discussion there. >>>>> >>>>>> >>>>>> John B. >>>>>> >>>>>> On 19-Aug-09, at 8:10 PM, Nat Sakimura wrote: >>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> Ah! I think it is so called "Framing Problem". >>>>>>> >>>>>>> When I modified the 2.0 spec to create this 2.1 draft 0.001, I have >>>>>>> removed all the restrictions that authentication messages have to >>>>>>> be >>>>>>> indirect. So, now, it can be direct as well. When using direct, >>>>>>> to link it >>>>>>> with user action, the artifact is used. >>>>>>> >>>>>>> See inline: >>>>>>> >>>>>>> On Thu, Aug 20, 2009 at 1:52 AM, John Bradley >>> >>> <[email protected] >>>>>>>> >>>>>>> wrote: >>>>>>> Hi Nat, >>>>>>> >>>>>>> inline >>>>>>> >>>>>>> >>>>>>> On 19-Aug-09, at 12:32 PM, Nat Sakimura wrote: >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> Inline: >>>>>>> >>>>>>> On Wed, Aug 19, 2009 at 10:30 PM, John Bradley >>> >>> <[email protected] >>>>>>>> >>>>>>> wrote: >>>>>>> Nat, >>>>>>> >>>>>>> On a first read through. >>>>>>> >>>>>>> Your proposal only solves half the problem, in that it only >>>>>>> reduces the >>>>>>> size of the indirect response. With extensions it is still >>>>>>> possible to >>>>>>> likely that requests will go over 2K. >>>>>>> >>>>>>> Why is that so? >>>>>>> All the extensions can use this direct communication path. >>>>>>> What was sent over indirect communication is sent over direct >>>>>>> communication. >>>>>>> >>>>>>> >>>>>>> If the full request must be made indirectly that doesn't reduce the >>>>>>> request size. >>>>>>> >>>>>>> As stated above, the full request can be made directly. In that >>>>>>> case, >>>>>>> only artifact and a few others moves indirectly. Thus, it will >>>>>>> reduce the >>>>>>> request size drastically, putting upper bound for the indirect >>>>>>> request size. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Are you thinking that the authentication is done via a indirect >>>>>>> request >>>>>>> but CX, AX etc all happen via direct communications? >>>>>>> >>>>>>> No. Main body of Authentication request, and thus extension >>>>>>> requests, are >>>>>>> sent via direct request and only the artifact and a few others >>>>>>> are sent via >>>>>>> indirect communications. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Unless you send the attributes that are going to be requested in >>>>>>> the >>>>>>> indirect request how would the user provide consent to release >>>>>>> them to the >>>>>>> RP? >>>>>>> >>>>>>> The request is sent from the RP to the OP over the direct >>>>>>> communication. >>>>>>> Then, the user is taken from the RP to the OP over the indirect >>>>>>> communication carrying the Artifact. The OP, upon receipt of the >>>>>>> Artifact, >>>>>>> can reconstruct the main request from it. Then, the user consent >>>>>>> etc. >>>>>>> happens as usual. Then, instead of the OP sending the positive >>>>>>> assertion >>>>>>> back to the RP, it sends the Artifact and the user back to the RP >>>>>>> over the >>>>>>> indirect communication signifying that it has completed the >>>>>>> processing at >>>>>>> the OP. Using the Artifact, the RP fetches the (+ve or -ve) >>>>>>> assertion from >>>>>>> the OP through the direct communication. Verification etc. goes >>>>>>> on then as >>>>>>> usual there after. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Also openID relies on validating the users presence via a >>>>>>> cookie. That >>>>>>> would not be available to the OP in a direct session. >>>>>>> >>>>>>> Hopefully now you see why it works. It changes almost nothing. It >>>>>>> just >>>>>>> pushes the main payload to the direct communication and that's >>>>>>> it. Others do >>>>>>> not change. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I would prefer not to have to revisit this again once the request >>>>>>> size >>>>>>> becomes an issue. >>>>>>> >>>>>>> The OP needs to advertise that it supports the binding in it's >>>>>>> XRD/S. >>>>>>> >>>>>>> In this draft, I made the support of direct communication >>>>>>> mandatory and >>>>>>> the version of the OpenID Authn protocol was raised to 2.1. This is >>>>>>> advertising that it supports the binding in its XRD/S. >>>>>>> >>>>>>> >>>>>>> I don't know that making it mandatory is necessarily a good >>>>>>> idea. There >>>>>>> may be other things in 2.1 that may be useful aside from a >>>>>>> artifact binding. >>>>>>> >>>>>>> I prefer the idea that a OP could optionally support the binding >>>>>>> and it >>>>>>> would be discoverable. >>>>>>> >>>>>>> I don't feel super strong about it, but others may. >>>>>>> >>>>>>> Right. I just wanted to be a minimalist and also wanted the spec >>>>>>> to be >>>>>>> fairly symmetric. If the artifact is to be an optional binding, >>>>>>> then it >>>>>>> would have to define a new type URI. However, from the sake of >>>>>>> being >>>>>>> symmetric, then, we should define type URI for the indirect >>>>>>> binding as well >>>>>>> and list it on XRD/S. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> As you point out this doesn't do anything for security. The >>>>>>> artifact >>>>>>> will need to be encrypted or mutual TLS used for the direct >>>>>>> connection. >>>>>>> >>>>>>> The encryption of the Artifact is an open question, as SAML >>>>>>> Artifact >>>>>>> binding does not encrypt the Artifact either siting that in this >>>>>>> limited >>>>>>> size that the encryption is unpractical. >>>>>>> >>>>>>> For the mutual authentication, I could incorporate relevant >>>>>>> sections of >>>>>>> CX here as well. That will make the already thin CX spec even >>>>>>> thinner. >>>>>>> >>>>>>> >>>>>>> You are going to make me read CX aren't you:) >>>>>>> >>>>>>> Yes. If you leave the contract schema alone, then it is extremely >>>>>>> concise. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> In testing something close to 1% of RP and OP have TLS implemented >>>>>>> correctly now. Mutual TLS may impossible to implement in some >>>>>>> environments. >>>>>>> >>>>>>> It is easy to say just use TLS for that, and make it someone else's >>>>>>> problem. Mutual TLS may be the best option but encrypting the >>>>>>> fragment and >>>>>>> using normal TLS should also be considered. >>>>>>> >>>>>>> Having the OP POST to the RP directly should also be considered, >>>>>>> that >>>>>>> would work for LoA 2 but probably not LoA 3 without mutual TLS. >>>>>>> >>>>>>> That's unsolicited direct response, and it is not precluded in this >>>>>>> draft. >>>>>>> >>>>>>> >>>>>>> No unsolicited assertions are still indirect. >>>>>>> >>>>>>> As I have explained above, in this draft, unsolicited assertions >>>>>>> can be >>>>>>> direct. It may have no association with the user session as well. >>>>>>> If it >>>>>>> does, then the user has to be at the OP to start with, and the >>>>>>> User has to >>>>>>> be taken to the RP with the Artifact. >>>>>>> >>>>>>> >>>>>>> I was thinking of a flow where the OP makes two replies one >>>>>>> indirect and >>>>>>> the other direct. >>>>>>> >>>>>>> That is exactly what is in my draft, though the indirect one is >>>>>>> optional. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The main reason not to do this is that it would not work with RP >>>>>>> load >>>>>>> balancing. Likely they go to different servers. >>>>>>> >>>>>>> We have that problem now with nonces. >>>>>>> >>>>>>> I think this is an implementation problem. >>>>>>> >>>>>>> The implementation should have some kind of shared storage behind >>>>>>> the >>>>>>> server farm and store the direct response to with the Artifact as >>>>>>> the key. >>>>>>> When the user landed on one of the server, the server can pull >>>>>>> the data from >>>>>>> the shared storage, and that's it. >>>>>>> >>>>>>> Note that the unsolicited direct response without user being >>>>>>> taken back >>>>>>> to the RP works. It works for AX update etc. >>>>>>> >>>>>>> Also, I have constructed the protocol to be "easier to implement" >>>>>>> for >>>>>>> RPs. >>>>>>> If they do not support unsolicited direct response, that is still >>>>>>> OK. >>>>>>> It is only this feature that uses the OP to the RP communication >>>>>>> unlike >>>>>>> SAML's case. >>>>>>> It is always the RP making request to the OP. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Artifact binding is simple in principle but the devil is in the >>>>>>> details. >>>>>>> >>>>>>> Is there anything else? >>>>>>> We can create an issue tracker and solve them one by one. >>>>>>> I actually do not foresee too many of them. >>>>>>> Also, we should not try to solve all the use cases. >>>>>>> Being able to satisfy 90% of them should be good enough. >>>>>>> >>>>>>> >>>>>>> >>>>>>> John B. >>>>>>> >>>>>>> >>>>>>> >>>>>>> There are a number of tradeoffs with different methods. >>>>>>> >>>>>>> A good attempt to show how this method would work. >>>>>>> >>>>>>> John B. >>>>>>> >>>>>>> >>>>>>> On 19-Aug-09, at 5:51 AM, Nat Sakimura wrote: >>>>>>> >>>>>>> Been sick and not following the various discussion around >>>>>>> artifact since >>>>>>> last Saturday, so I might be out of sync but here is my shot for >>>>>>> Artifact >>>>>>> Binding which I hoped to provide on Friday 14th. >>>>>>> >>>>>>> http://wiki.openid.net/OpenIDwithArtifactBinding >>>>>>> >>>>>>> It is about 40 lines of modification/addition. The portion that I >>>>>>> changed/added are in RED so it should be easy for you to find out. >>>>>>> >>>>>>> Its sequence is a bit different than SAML Artifact binding as I >>>>>>> tried to >>>>>>> minimize the impact to the current deployments. >>>>>>> >>>>>>> It has done nothing about encryption. The direct communication >>>>>>> should be >>>>>>> over the verified TLS channel. Security implication of the >>>>>>> Artifact exposure >>>>>>> on the indirect communication should be further discussed, but my >>>>>>> preliminary assessment is that it should be ok. >>>>>>> >>>>>>> =nat >>>>>>> >>>>>>> On Wed, Aug 19, 2009 at 8:42 AM, Dick Hardt <[email protected] >>> >>>>>>>> >>>>>>> wrote: >>>>>>> my $0.02 >>>>>>> >>>>>>> I expect the data moving between the RP and OP to become even >>>>>>> larger over >>>>>>> time, therefore a standard, alternative mechanism for moving the >>>>>>> data >>>>>>> directly between the RP and OP, particularly when bandwidth to >>>>>>> the client is >>>>>>> constrained, seems desirable. >>>>>>> >>>>>>> I would generally prefer a proven, widely deployed encryption >>>>>>> mechanism >>>>>>> such as TLS rather then adding functionality to OpenID >>>>>>> >>>>>>> -- Dick >>>>>>> ________________________________________ >>>>>>> From: [email protected] >>>>>>> [[email protected]] on behalf of John Bradley >>>>>>> [[email protected]] >>>>>>> Sent: Tuesday, August 18, 2009 3:27 PM >>>>>>> To: Allen Tom >>>>>>> Cc: [email protected] >>>>>>> Subject: Re: Artifact Binding Re: specs Digest, Vol 36, Issue 1 >>>>>>> >>>>>>> One of the things you need for LoA 2 is to prevent eavesdropping. >>>>>>> >>>>>>> The choices are encrypt the response to the RP or use direct >>>>>>> communication with TLS (probably mutual) if the RP is going to >>>>>>> make a >>>>>>> direct request to the OP. >>>>>>> >>>>>>> Using an artifact binding has advantages and disadvantages. >>>>>>> Using it >>>>>>> to get around the 2K URI limit in IE would put any RP not >>>>>>> supporting >>>>>>> it at a disadvantage. >>>>>>> >>>>>>> It might be acceptable if the RP could indicate its support for >>>>>>> artifact binding in the request and allow the OP to use artifact >>>>>>> instead of post. >>>>>>> >>>>>>> With mobile devices becoming more common I can see people >>>>>>> preferring >>>>>>> an artifact binding over the existing ones. >>>>>>> >>>>>>> It is a real change to the protocol and will add complexity >>>>>>> supporting >>>>>>> another binding. >>>>>>> >>>>>>> One short term fix that Andrew Arnott implemented in >>>>>>> DotNetOpenAuth is >>>>>>> a smart detection of OP's support for AX vs SREG and preferring >>>>>>> SREG >>>>>>> if it is supported. Most people are only using AX for the SREG >>>>>>> attributes anyway. >>>>>>> >>>>>>> I agree that the AX attribute URI need to get sorted out >>>>>>> anyway. We >>>>>>> could look at making them shorter when we mint new standard ones. >>>>>>> >>>>>>> John B. >>>>>>> On 18-Aug-09, at 6:02 PM, Allen Tom wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Sorry for the delayed response, I'm still catching up on mail >>>>>>>> after >>>>>>>> being on vacation last week. >>>>>>>> >>>>>>>> Breno - How would artifact binding help OpenID attain Loa2? I'm >>>>>>>> unclear as to how that would make a difference. >>>>>>>> >>>>>>>> The Yahoo OP was recently updated to return responses that are >>>>>>>> larger than 2KB using POST, and this has caused many users to see >>>>>>>> the ugly browser warning because most RPs don't support HTTPS. >>>>>>>> Displaying the ugly browser warning is really unacceptable, so >>>>>>>> we'll >>>>>>>> probably update the Yahoo OP to only use POST only for HTTPS >>>>>>>> return_to URLs. >>>>>>>> >>>>>>>> The excessively large responses are mostly due to AX being >>>>>>>> excessively verbose. It would be really nice if we could revise AX >>>>>>>> to be a lot more compact. Perhaps if we had a standardized AX >>>>>>>> schema, we'd be able to shorten the message size. >>>>>>>> >>>>>>>> Allen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Breno de Medeiros wrote: >>>>>>>>> >>>>>>>>> Since Google was mentioned here as wanting artifact, let me >>>>>>>>> make the >>>>>>>>> record clear to say that I spoke about artifact binding on my >>>>>>>>> personal >>>>>>>>> capacity. >>>>>>>>> >>>>>>>>> My very own personal view is that an artifact profile would be >>>>>>>>> easy >>>>>>>>> to >>>>>>>>> spec out (the check_authentication or stateless mode is already >>>>>>>>> the >>>>>>>>> artifact flow without the additional benefits of artifact) and >>>>>>>>> would >>>>>>>>> make OpenID more robust. Currently long URLs require POST which >>>>>>>>> only >>>>>>>>> gives you so much mileage. POST is ugly if the RP has a non-HTTPS >>>>>>>>> endpoint, with scary user confirmation dialogs. >>>>>>>>> >>>>>>>>> Also, I did not wish to express any personal opinion on whether >>>>>>>>> OpenID >>>>>>>>> should seek Loa2, just to note that artifact is the easiest route >>>>>>>>> there. >>>>>>>>> >>>>>>>>> On Thu, Aug 13, 2009 at 10:45 AM, Nat >>>>>>>>> Sakimura<[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> John, >>>>>>>>>> You changed the topic of this thread. >>>>>>>>>> This thread was about artifact binding, not about Government >>>>>>>>>> LoA. >>>>>>>>>> That's another thread :-) >>>>>>>>>> Yes, Artifact helps LoA, but it is not only that. >>>>>>>>>> It helps the mobile space immensely. >>>>>>>>>> =nat >>>>>>>>>> >>>>>>>>>> On Fri, Aug 14, 2009 at 2:00 AM, John Bradley <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Chris >>>>>>>>>>> I think we are agreeing. OpenID needs to play to it's >>>>>>>>>>> strengths. >>>>>>>>>>> Chasing shiny things is tempting. >>>>>>>>>>> We need to carefully consider the impact of changes. >>>>>>>>>>> That is not to say that openID shouldn't evolve. >>>>>>>>>>> There are always tradeoffs. >>>>>>>>>>> Remember that a GSA LoA 2 or 3 profile is focused on the Gov >>>>>>>>>>> accepting the >>>>>>>>>>> assertions for specific uses. >>>>>>>>>>> Other people are free to make there own determinations for >>>>>>>>>>> other >>>>>>>>>>> use >>>>>>>>>>> cases. >>>>>>>>>>> I am interested in finding out if IdP really want to be >>>>>>>>>>> certified >>>>>>>>>>> at LoA 2 >>>>>>>>>>> with all of the extra identity >>>>>>>>>>> proofing, liability and other things that go with that. >>>>>>>>>>> A LoA 2 certification for a IdP involves a lot more than just >>>>>>>>>>> tweaking >>>>>>>>>>> some protocol peaces. >>>>>>>>>>> Are there OPs that want that? >>>>>>>>>>> John B. >>>>>>>>>>> On 13-Aug-09, at 9:11 AM, Chris Messina wrote: >>>>>>>>>>> >>>>>>>>>>> On Thu, Aug 13, 2009 at 8:34 AM, John Bradley >>>>>>>>>>> <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Some may ask if we add artifact binding, signatures and >>>>>>>>>>>> encryption are we >>>>>>>>>>>> not reinventing SAML Web SSO, or something of equal >>>>>>>>>>>> complexity? >>>>>>>>>>>> >>>>>>>>>>> I would like to know more about this, but my instinct is always >>>>>>>>>>> to say >>>>>>>>>>> "NO" for as long as possible when any new feature will a) >>>>>>>>>>> introduce >>>>>>>>>>> complexity and b) stifle or impair potential adoption. >>>>>>>>>>> That we've come as far as we have is a feat; maintaining that >>>>>>>>>>> momentum is >>>>>>>>>>> critical — and that means making good on the promise of what >>>>>>>>>>> OpenID offers >>>>>>>>>>> *today* — and only extending it with real world examples where >>>>>>>>>>> people are >>>>>>>>>>> implementing kludges (en masse) to serve a common need. >>>>>>>>>>> >>>>>>>>>>> Chris >>>>>>>>>>> -- >>>>>>>>>>> Chris Messina >>>>>>>>>>> Open Web Advocate >>>>>>>>>>> >>>>>>>>>>> Personal: http://factoryjoe.com >>>>>>>>>>> Follow me on Twitter: http://twitter.com/chrismessina >>>>>>>>>>> >>>>>>>>>>> Citizen Agency: http://citizenagency.com >>>>>>>>>>> Diso Project: http://diso-project.org >>>>>>>>>>> >>>>>>>>>>> OpenID Foundation: http://openid.net >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This email is: [ ] bloggable [X] ask first [ ] private >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> specs mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Nat Sakimura (=nat) >>>>>>>>>> http://www.sakimura.org/en/ >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> specs mailing list >>>>>>> [email protected] >>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Nat Sakimura (=nat) >>>>>>> http://www.sakimura.org/en/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Nat Sakimura (=nat) >>>>>>> http://www.sakimura.org/en/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Nat Sakimura (=nat) >>>>>>> http://www.sakimura.org/en/ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Nat Sakimura (=nat) >>>>> http://www.sakimura.org/en/ >>>>> >>>>> _______________________________________________ >>>>> specs mailing list >>>>> [email protected] >>>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>>> >>>>> >>>> >>>> >>>> >>>> >> _______________________________________________ >> Specs-cx mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs-cx > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
