unverified claims

Today WS-Policy was approved as a W3C Recommendation. With that we can now say that there are standard versions of the WS-* specifications for building secure, transactable, addressable and reliable web services that are policy driven.

As I see now that I never addressed my own post on WS-SecurityPolicy being up for approval as an OASIS standard (yes it was approved) a brief recap of the WS-* specifications approved as standards this year seems in order.

WS-SecureConversation 1.3 OASIS Standard

WS-Trust 1.3 OASIS Standard

WS-Coordination 1.1 OASIS Standard

WS-AtomicTransaction 1.1 OASIS Standard

WS-ReliableMessaging 1.1 OASIS Standard

WS-SecurityPolicy 1.2 OASIS Standard

WS-Policy 1.5 W3C Recommendation

WS-Addressing 1.0 Metadata W3C Recommendation

Quite a list! I’m sure I’m missing some and I left some related specifications to the ones above out of the summary. Of course this all builds on top of existing standards like SOAP and WSS.

Will there be more? Sure, things always continue to evolve. WS-Federation was just submitted to OASIS this year for example. So while this isn’t the end it is an important milestone.

Now you can associate an Information Card with your Live ID. No more passwords! Hurray!

Here are the details of how to configure CardSpace for use with Live ID.

Time to change the picture on my card.

SXIP has published a spec defining OpenID Information Cards. They have also put up a provider where you can get one of these cards, an RP test it with and the source. This looks like something worth playing with.

Mike Jones has more details on how OpenID Information Cards work.

(*sigh* - corrected link to actually go to Mike’s post)

Well this is cool, WSO2 just released a PHP extension to support WS-* including WS-ReliableMessaging and WS-SecurityPolicy.

Wow. This is an interesting description a compromise at Monster that has been used for targeted attacks. With the data that has been compromised the spam used in those targeted attacks would be pretty convincing. Apparently it stems from a few compromised customer accounts at Monster. One wonders what other accounts have been compromised through this attack. One wonders if any of the owners of the initially compromised accounts were friends with a frog.

WS-SecurityPolicy is a keystone in enabling secure web services. This specification provides a set of WS-Policy assertions for describing the desired security characteristics of web service messages. More specifically it provides the ability for the expression of requirements related to WSS, WS-SecureConversation and WS-Trust. This specification has been under development within the OASIS WS-SX TC for over a year now. I’m happy to say that the OASIS member familiarization period for the specification began this month. So what does that mean?

At OASIS a specification must be approved by at least 15% of the membership to become an OASIS standard. When a specification is deemed mature enough by a an OASIS Technical Committee (TC) it is submitted to the OASIS staff. The staff then initiates a member familiarization period on the first of the month after the request is made. The membership has 15 days to become familiar with the specification. On the 15th of the month the specification is placed on a ballot on which the voting representative for each member company at OASIS can cast a vote in favor or opposed to the specification becoming an OASIS standard.

If your company is an OASIS member and you are not familiar with the specification now is the time. Copies of the specification in all of you favorite document formats can be found at the WS-SecurityPolicy namespace location: http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702

Will I be back here asking for your vote come the 15th of June? You’d better believe it.

Last week Microsoft and IBM published the Understanding WS-Federation (html | pdf) white paper. 

As Don has already said the paper covers two scenarios in which different features of WS-Federation are demonstrated. I think the two scenarios chosen provide an accessible introduction to these features.

The first example covers an enterprise business scenario around an RFP service. This example shows a simpler federation scenario between two participants. The second example is a healthcare scenario around access to patient records. This a more complicated example involving three participants. The paper is not exhaustive in its coverage of the specification but it wasn’t intended to be. I think we did hit a good balance between breadth and depth. Anyone who reads this paper should come away with a good handle on the capabilities of WS-Federation and how it builds upon WS-Trust.

We’ll be covering some of this material at the first meeting of the WSFED TC next week, I’ll provide an update on that here after the meeting.

Yes, I think I’ve been here before.

I’ve even found bits I could recycle to explain myself, I had to change more characters than words to update it. That scares and comforts me.

This place is going to be used for my own musing and linkings to things related to security. That’s specific and broad enough for now. I expect for most of this too be on identity and web service security related topics, but I’m sure I’ll find things within the realm of security that won’t fit in those buckets to mention as well.

Now… to get it and keep it going.