CLAIM-REQUEST: username, password

[Paul Trevithick]

See the two new rows here [1].

--Paul

[1] https://informationcard.net/wiki/index.php/Claim_Catalog#New_Requests

[Axel.N...@telekom.de]

In what respect does this request differ from the one last time we had this discussion?

What is the difference to

http://groups.google.com/group/icf-wg-schemas/browse_thread/thread/c582448e5a4e4560 ?

 

Requiering Anti-Phishing is too vage, I think.

Wasn't one of the outcome of the last discussion that a standard URI for username and password makes no sense given the tight coupling between RP/IdP in this use case?

We wanted to make sure that the user does not use his username/password card from site X at site Y; which could be the case if there are several cards with this two claims but from different sites? Relying on that the RP requests a specific issuer of the token is not enough.

 

I think that each site that needs username and password claims should invent its own URI and suggest that the URI is the absolute URL of the action-parameter of the form where the token is posted to.

I think we should NOT standardize username and password claims but instead create a paragraph on the claims-page where we explain why we do not standardize them and how each site that requires these beast should invent them for themselves.

 

-Axel

 

---

Von: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com] Im Auftrag von Paul Trevithick
Gesendet: Montag, 23. März 2009 19:18
An: ICF.WG.Schemas
Betreff: [ICF.WG.Schemas] CLAIM-REQUEST: username, password

[John Bradley]

Axel,

Yes we agreed that is the approach that people should take when a site is running its own RP to password gateway.

These claims are ones that a plugin or other App acting as an RP on the uses computer would use.

Think of a password manager that wants to store information in the cardstore.

Some people will be concerned about the lack of security or authentication method between the selector and other applications on the computer.   However that is outside the scope of the schemas work group.

John B.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "ICF-WG-Schemas" group.
To post to this group, send email to icf-wg-...@googlegroups.com
To unsubscribe from this group, send email to icf-wg-schema...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/icf-wg-schemas?hl=en
-~----------~----~----~----~------~----~------~--~---

[Axel.N...@telekom.de]

issuer == "urn:icf:2009:passwordmanager" ?

IsSelfIssued == false

TokenType = "urn:icf:2009:username_password_token"

 

How does a selector decide that

cardA is for http://hostA.mycompany.com:portA/pathA and

cardB1 for http://hostB.mycompany.com:portB/pathB

cardB2 for http://hostB.mycompany.com:portB/pathC

What if the issuer not fixed like my suggestion in the first line of this email but http://hostA.mycompany.com:portA/pathA when the claims are like currently requested?

 

--

if this is outside the scope of this WG then we should not define these claims here but e.g. in the Browser-Integration-WG together with the other values like issuer, IsSelfIssued etc

 

--

Does somebody feel inclinded to give a fully specified RoamingInformationCard example?

 

-Axel

 

---

Von: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com] Im Auftrag von John Bradley
Gesendet: Montag, 23. März 2009 20:43
An: icf-wg-...@googlegroups.com
Betreff: Re: AW: [ICF.WG.Schemas] CLAIM-REQUEST: username, password

[John Bradley]

Good question:)

There are a lot of unknowns about how cards can work with a local app.    

I think there is a lot of work to be done before there is anything portable or interoperable.     

John Bradley

[Paul Trevithick]

Axel,

The answer to your first question is that the password manager must pass a parameter in addition to requesting the un/pw claims.

Originally I had been thinking of proposing a generic ICF “webpage” claim and using your “?” mechanism to allow the RP (password manager) to pass the URL of the webpage (e.g. <generic-webpage-claim-uri> ? page=hostA.mycompany.com:portA/pathA).

When we were on the call today, we collectively decided to remove mention of this parameter as there is not yet agreement on how RPs pass parameters along. (I had originally included mention of it in the wiki page).

The Higgins project is working on a password manager [1] where the issuer would be static, as in your email. As mentioned above we had been thinking of using the “AxelN” (“?”-based) parameter passing mechanism. And we will probably just continue along these lines at least until the ICF’s Selector Integration WG comes up with an alternative. We’ll just define a Higgins-specific “generic” webpage claim (e.g. http://eclipse.org/higgins/claims/webpage) instead of standardizing at the ICF.

--Paul

[1] http://wiki.eclipse.org/Password_Cards

On 3/23/09 5:10 PM, "Axel.N...@telekom.de" <Axel.N...@telekom.de> wrote:

[Markus Sabadello]

This may be a stupid comment, but isn't what you're looking for an "auditing card"? I mean, an auditing card does exactly that, i.e. the issuer is told where the card is about to be used, no?

Markus

[Paul Trevithick]

Not quite. Let me explain by looking at the design of a password manager browser plugin. There are two design options: “proxy” and “app.

proxy: The password manager acts as a proxy for the "real" RP --thus the domain in the RST is the domain of the site the browser is pointing at

app: The password manager IS the RP --it has its own domain/identity --thus the domain in the RST is the domain of the password manager.

In the “app” approach the issuer in the RST would always be same domain (that of the password manager itself), so auditing won’t help, and we need this parameter to be passed. In the “proxy” case you also need this parameter, but for a different reason. In the proxy case only the domain name of the RP (e.g. Amazon.com) is passed in the RST, the path portion isn’t present. For reliable un/pw form filling we need to match on the full path, not just the domain. So again the parameter is needed. The Higgins project’s password manager uses the “app” design option. See [1] for some details.

---Paul
[1] http://wiki.eclipse.org/Password_Manager_Design_Options

[Ian Hummel]

Hi Paul,

Actually with Auditing cards and current selectors the full path/URL is passed in the RST.  Section 4.3.3 of ISIP 1.5 specifies how a selector should send along "Token Scope" information... although exactly what "Token Scope" means could be spelled out in more detail (is it the hostname?  The full URL?  The full URL + the HTML ID of the form?)

Maybe we can just say that for password cards the selector should send along e.g.  ?

http://mysite.com/login/loginPage.jsp#loginForm    (#loginForm is the id of the form, if applicable)

In that case a password manager would have all the info it needs, right?

FYI, here is an example from an auditing card and azigo:

<wsp:AppliesTo>

  <wsa:EndpointReference>

    <wsa:Address>https://watch-this.com/watchthis/verify.do</wsa:Address>

      <wsid:Identity> 

        <ds:KeyInfo>

          <ds:X509Data>

            <ds:X509Certificate>

... cert data....

            </ds:X509Certificate>

          </ds:X509Data>

        </ds:KeyInfo>

      </wsid:Identity>

  </wsa:EndpointReference>

</wsp:AppliesTo>

And here is the same card using CardSpace

<wsp2004:AppliesTo>

  <a:EndpointReference>

    <a:Address>https://watch-this.com/watchthis/verify.do</a:Address>

    <Identity>

      <KeyInfo>

        <X509Data>

          <X509Certificate>

            ... cert data ...

          </X509Certificate>

          <X509Certificate>

           ... more cert data...

          </X509Certificate>

        </X509Data>

      </KeyInfo>

    </Identity>

  </a:EndpointReference>

</wsp2004:AppliesTo>

[John Bradley]

Ian,  

This is true where the RP is a site with a cert that is triggering an auditing-mode/audience restricted card.

The cert from the RP is passed in the message and the token is encrypted with the RP's PK from the cert.

In this senario the password manager would need to pretend to be the RP and place the post URI for the loggin form in the <wsp:AppliesTo:wsa:EndpointRefrence:Address> 

If we are messing with the selector probably the correct element to use is actually 

<wsp:AppliesTo:wsa:EndpointRefrence:wsid:Identity:Upn> or

<wsp:AppliesTo:wsa:EndpointRefrence:wsid:Identity:Spn>

See sec 12.2 of the IMI spec.

If you are doing this outside of the selector without selector complicity,  you need to fake being a relying party without a certificate to avoid the token being encrypted.

See Sec 8 if the IMI spec.

The wsp:AppliesTo is still sent an the token is not encrypted.

I remain unconvinced that allowing a non-ssl endpoint of request unencrypted tokens with passwords as a good idea.

I am interested in finding out how in the spoofing the client theory of password managers we can prevent other apps on the computer or infract other remote non-ssl RPs from requesting the unencrypted token?

That is why I am leaning towards treating the password manager as the RP that way we stand some chance of only handing back these tokens to the appropriate RP ie the users password manager.

I have a feeling that changes to how the selector interacts with the world will be required to allow safe interactions with local applications.   

Things like how is a local app supposed to express its WS-SecurityPolicy to the selector is this at localhost via ssl?

The existing interaction and selector API at least in the higgins case is intended for a RP -> browser -> Selector -> IP/STS interaction.

Perhaps one way to deal with local apps is to define a way for them to publish an RP/STS locally on the same host as the selector.   Assuming that we could answer the SSL issues with some sort of cert that works in that env perhaps self signed.

That would give us a much richer tool set to work with that trying to fit entirely inside what we think of as the normal browser interaction.

What has been proposed to this point are largely hacks to add on functionality that is desired by people in the community.

I cant stop the hacks,  people have product to deliver.  However we do need something that is properly designed,  but that will not happen over night.   Lets just not break things too badly in the interim.

Regards

John Bradley