Common Misconception: Username/Password Tokens

People new to Information Cards sometimes think that Information Cards are used to transport username and password to login at a relying party....
Well, Information Cards could be used for that but this is a stupid idea.

First it is incomprehension. Then you start to think: "Why not. This could make the life of a relying party easier. They know how to handle username and password, so let's give it to them". Bad idea.

When you use the security token to transport username and password and you use nothing but username and password from the token then you are giving away the advantages of the whole concept.
There need to be changes to the RP's software to disassemble the security token anyway. When you accept this then you should accept that you can then use the security features of the token too. Each library that can disassemble the token can validate it too. It does not hurt to check the validity dates of the security token. It does not hurt to verify the signature of the security token. If the backend system is so old and inflexible that you must provide two strings for authentication then use a variation of e.g.: uid=PPID, pwd=public-key-base64 or uid=username, pwd=PPID or uid=first-8-bytes-from-PPID, pwd=8-bytes-from-public-key-hash-from-selected-but-fixed-positions. But you must check the signature. Only the owner of the private key could sign the security token and the private key is never transferred to the anybody. This is THE advantage compared to username and password. You can not forge the security token even if you know username and password.

Don't invent username/password-tokens. Don't do evil.