I expect the shirt Pat wore accounts for his inflated ratings. 
Who does this? Who is so insulated from dealing with their own spam that they are oblivious to the risk that giving away email addresses would mean for their friends or family?Overall, as far as I can tell, there is nothing in this specification that is not easily handled using the SAML Authentication Context structure and so I don't understand why they didn't just adopt that model as-is (and the SAML model clearly handles much more than the limited cases supported currently by this proposal). At the minimum, this document should be a limited profile of what portions of the SAML model they want to use.The proposal's acknowledgement of the similarity between AQE and SAML AC isn't enough.
This is all you hear from or about SAML in the entire specification. There are no other references to the SAML authentication context, nor any use of the structures or capabilities of the Authentication Context. I'm not sure why this is even mentioned here if they aren't going to make use of any of the SAML work in this area.Personally (and I'm not speaking for David or Avery) I see OpenID leveraging SAML Authentication Context as a desirable end-state (as do I seeas desirable SAML possibly leveraging those pieces of OpenID for which there is no comparable existing functionality in SAML 2.0) and hope that AQE gets us closer to that end-state. Afterall, you can't converge if you don't have two parts to align.
The Security Assertion Markup Language (SAML) Authentication Context ([SAMLAC] (Kemp, J., “SAML 2.0 Authentication Context,” 2005.) defines mechanisms by which SAML Service Providers and OpenID Providers can discuss the context of an authentication assertion.
The authors acknowledge the similar motivation between SAML's Authentication Context and this extension. Where possible, we have attempted to stay aligned with the SAML Authentication Context model. Indeed, we see this topic as a likely area of convergence between OpenID and SAML. More work is needed here.
Not sure what to make of this. One of the purported justifications for the Cardspace 'greying-out' is to produce a visual effect that would be difficult for a phish site to recreate. But, any phish site could recreate the effect within the browser and it's modal only within the browser (actually only within the tab).
I thought it might have been a 'To Do List' GreaseMonkey script I was trying out so I uninstalled that. No change. Cleared cache and cookies. No deal. Using an 'https' URL resolved the issue.provides a fast and convenient way for people with food allergies to print off "allergy cards" for use eating out, while travelling, etc.
And then there are the inames. I can't figure out when exactly I get to start using my iname to authenticate, and if I do, do I still need to specify a provider? I remember from IOS Santa Clara that inames & open IDs are merging for OpenID 2.0, I just can't figure out if that means now, or soon... luckily I get to ask all these types of questions at IIW in a few weeks :)As I understand it, in OpenID 2.0, if you provide the RP your i-name, the RP would use XRI resolution to retrieve an XRDS document, and from that extract the appropriate IDP endpoint for redirection.
Actually, it does appear to do more than this. When I leave 'LiveJournal User' selected, and provide my Verisign PIP OpenID URI, I get an error message of 'Couldn't find OpenID Server'. When I switch to select 'Other OpenID' and provide the same URI, I am successfully directed to Verisign's PIP.
From looking at the code for the plug-in, the only real purpose of the drop down box is to change the icon within the field next to it to match the type of server you will be using. Other than changing the icon, it serves no real purpose.
It's not clear to me why a user would need to both supply the URI as well as indicate the IDP through the select list?as each Freedom Fund nears its target date, the investment mix gradually gets more conservative.As you near the time where you will be removing funds, the asset allocation changes to minimize risk.
Begin by studying various SAML Profiles, e.g. those given in [[SAMLProf]] and [SIP-SAML]. One will likely find the SAML Technical Overview whitepaper [[SAMLTechOvw]] helpful in this endeavor. It provides a detailed, illustrated expose of several of the SAML Web SSO profiles.Interestingly, when I view the document, a plugin Skype (yes Jeff, I know it's proprietary) installed when I recently upgraded renders a phone number in one of the XML examples as a 'click to call'.
Presents some intriguing possibilities for smart clients. 
Aldo has an interview with Drummond Reed, Johannes Ernst, and Chris Messina talking about the importance of usability design and user experience to OpenID. If there exists a region of anonymity relatively devoid of identity, identifying information from the environment surrounding that region will attempt to redistribute itself so as to fill said void.As an exercise I leave it to the reader to develop the "'Surfing Adult Sites at Work' Corollary".
Transaction authentication is software residing on the enterprise security servers that monitors, in addition to the successful use of user id and password the:What if the scope of the 'transaction' were broadened, i.e. to include behaviours performed at an SP after the user SSO'd in from an IDP?
- IP address the user is coming in from
- Users geolocation
- Computer hardware the user is using
- Time of day
- Previous user pattern of behaviour
Julian's post alerted me to his Last.fm profile. I got to say that I'm a sceptic on this. I don't think that there has been an existence proof for the successful combination of SAML and Web 2.0: putting control in the hands of the end user — the essence of Web 2.0 — is not typically compatible with the way SAML projects tend to end up.The argument appears to be 'because SAML can be deployed in ways that don't directly/explicitly/visibly empower users, it can't be deployed otherwise'. Similiarly, because HTML can display porn, or violence, or politicians, it can't be used for more noble purposes.
Johannes points out the Open Healthcare Manifesto. 
So, both SAML and OpenID seem to have discovered distinct and valid islands. Nice. But, seems to me that both of late are exploring moving beyond these domains. OpenID is allowing for additional security options to OpenID 2.0, SAML to allowing for less security through the proposed SimpleSign binding. 
Differentiating between (and accounting for both) how the user was registered and how they were authenticated is something SAML's Authentication Context makes possible, most notable examples of which are the 4 mobile targetted AC class URIs that differentiate based on whether the user has a contracted account or is pay-as-you-go.
about the method of identification at the point of enrollment and the method used when authenticating
The RP doesn't have to bother but if it chose to it could keep track of those providers that provide strong auth and act appropriately when those IdP's are the ones doing the authentication.This could work if an IDP only supported a single authentication mechanism. If not, the RP wouldn't know which was used for any given assertion.
What higher level value is a claim of strong auth from an IdP when there is no trust between the IdP and the RP anyway?Indeed, but if the RP doesn't trust the IDP, its unlikely to care about how the IDP authenticated the user. And if the RP doesn't care, why would the IDP go to the extra cost and effort?
So, to LiveJournal, it thinks that you just went to any standard OpenID implementationTying in Strong Authn to SSO is great - the two pieces complement each other perfectly. Strong Auth gives SSO 'something to do' and provides value to the RP beyond convenience to the end users, and SSO makes Strong Authn practical and cost-effective.
.
.
it doesn't know that, instead of just putting in your log-in and your password, that you were actually going through and authenticating yourself by voice.
In reality, identity providers will never allow users to drive the partners with which they engage in identity transactions, unless the user(s) have leverage in their relationship with the providers and and also the identity provider has leverage over its partners too.This was actually the point I was trying to make. I think user's can indeed have this sort of leverage over providers, but ultimately it's granted to them at the discretion of the providers.
Jamie Lewis points out Seriosity. Carbon (Beta) is an enterprise productivity application, inspired by successful interactive games. It creates an economic system with its own currency and market that allows users to better manage their attention and that of others.Sounds like the model is "Read this email and I'll slip you a fiver".
Jeff has updated the SAML Glossary, making it available in HTML.
For some, this sort of club is what a federation is. But the above SAML (and SAML is of course strictly about federation so its the authority) definition for federation also allows for clubs with far less formal rules and processes and, in the extreme case, an open-door policy of everybody welcome. Hello AGP, this is BGP asking on behalf of 'Bob', what is the current location of 'Alice'?Nb: 'Bob' and 'Alice' in the above will generally be appropriate identifiers (possibly encrypted so that BGP can't see them) for the two users that AGP will either be able to recognize or be able to map into identifiers that it can.
1) Bob SSOs into BGP from his IDP
2) BGP discovers Bob's PS
3) BGP queries Bob's PS for list of friends
4) BGP requests an identity token for Alice
5) Bob's PS does some work behind the scenes to get an identity token for Alice
6) Bob's PS returns the identity token to BGP
7) BGP uses the identity token to query Alice's Discovery Service for Alice's Geolocation provider
8) Alice's DS returns the location of AGP and an encrypted identifier to use for Alice there
9) BGP sends above message to AGP
10) AGP returns Alice's location to BGP
11) BGP shows Alice's location to Bob
12) Alice and Bob decide to, yet again, 'take a break'.
...the limitations of quantum cryptography (e.g., a single continuous fibre or line of sight must exist between the two parties) suggest that it will only really be applicable to high security link encryption, and not necessarily to other current applications of cryptography.Sounds like quantum crypto and OpenID is a marriage made in heaven.
In addition, quantum key distribution requires that a pre-existing authentic channel must exist between the two parties. Typically, this will be realized by the two parties having a pre-shared symmetric key that they can use for authentication.
"as long as people are still having promiscuous sex with many anonymous partners without protection while at the same time experimenting with mind-expanding drugs in a consequence-free environment, I'll be sound as a pound!"
What we know, how we learned it, and when we learned it.Sounds like an IDP doesn't it?
(GAY) Network with homosexual tendencies
"Identity Context at one network locale for a given user can only impact the identity context for that user at another provider if some representation of the context at the first is communicated from the first to the second"Web SSO is a perfect example. For the fact of my authentication at an IDP to be of any value for my interactions with an SP, an assertion/claim as to the act of my authentication must get from the IDP to the SP. Providers aren't psychic after all. So, the principle holds for SSO it seems.
