Sorry Paul,
I thought the call was off due to Presidents Day etc.
On the openID claim, I am thinking that it should probably be an XRD claim.
That could potentially be layered on top of the Existing info-card RP without the need to add openID authentication support to the RP.
The subject or CID of the XRD is the openID claimed_id and could be verified via the token signature without additional network accesses.
Delivering the XRD in the token also allows for private discovery, in that for auditing mode cards the IdP can customize the delivered XRD for the RP depending on the services the user wants to disclose. oAuth access tokens could also be included to bootstrap the RP's access to those services.
The idea is similar to ID-ESF discovery only the initial discovery happens during the initial authentication.
I am still looking for someone who wants to try this approach before registering the claim.
On the idea of Username, password, domain, action claims for use in p-cards.
I take it that this is a way for a local application to interface with a card selector as a store and not something that is intended for a website RP to request, or at-least not directly request.
Perhaps we need an experimental category for things like this. Though I understand that that probably defeats the purpose of the claim request.
I suspect that to get this to work with standard card selection logic, the domain will need to be encoded into the name of the claim itself. So we need to something a bit strange with that one and define a base URI for the claim.
To prevent confusion I wouldn't want to call these anything that might get used on a m-card like Ian's proposed use case from the other week.
Perhaps something with pw-manager in the URI.
I am restricting my comments to the claims themselves, however the question of local applications requesting cards and a host of security issues that raises should probably be discussed someplace.
=jbradley