Re: [ICF.WG.Schemas] Re: Towards a claims language

[John Bradley]

Hi Axel,

The proposal is that we move the topic to the ICF OASIS WG to start
developing a proposal that will eventually go to the IMI-TC.

I would hope to get a number of proposals including one from MS on how
we might address the issue.

It is clear to almost everyone that it is necessary functionality.

The question is how to best incorporate it in the next update of the
IMI spec.

Regards
John B.

On 16-Mar-09, at 10:38 PM, Axel Nennker wrote:

>
> I don't want to spit into the soup before even someone came up with a
> soup receipt, but when I hear "claims language" some inside alarm
> bells start to ring. You might remember the Prolog programming
> language and some tried to use it to describe TheWorld through
> predicate logic - that attempt failed. I think that an attempt to
> describe a "real" Persona through Claims will fail too. I believe that
> claims are a good invention and that they serve their purpose; but I
> fear that things might get out of hand when we start to get too
> complicated. "keep it simple" should be applied here too.
>
> I think that the schemas WG might be too specific for the problem we
> want to solve. I understand that this problem is
> "Allow payments by using Information Cards (with precondition:
> back channels are evil)"
>
> In the past we started some discussions one the ICF mailing-lists but
> we never came to a resolution.
> I would like to restart these discussions and would very much value
> the opionion of our fellow payment experts Sid Sidner and Andrew Nash.
> For the more technically inclined members the question is: "How do we
> conwey information from the RP to the IdP/STS in a user-centric way".
> ISIP currently does not allow this but it seems that we need this to
> enable payments.
>
> Another question "How do we ensure that the selector presents that
> information to the user in a way that she understands what is going
> on". We talked about this subproblem when we discussed moving from
> flat string claim's values to e.g. xml fragments (with mime types) as
> claim's values.
>
> -Axel
>
> On 17 Mrz., 05:31, Drummond Reed <Drummond.R...@parityinc.net> wrote:
>> Paul, excellent - sorry I missed that last part of the call, but I
>> was talking to a prospective ICF member.
>>
>> +1 to the query string being only a small first step towards the
>> robustness a claims language will need. I would expect MS to have
>> something based on WS-Policy. As you know, I have my own bias as to
>> why RDF - and in particular XDI RDF - fits the bill, but its an
>> open standard OASIS effort so all these things can apply as needed.
>>
>> I'm just glad to see that as a WG we are collectively recognizing
>> this need. I believe that within 6 months of starting to work with
>> a claims language we'll look back and wonder how we ever lived
>> without it.
>>
>> =Drummond
>>
>> ________________________________
>> From: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com
>> ] On Behalf Of Paul Trevithick
>> Sent: Monday, March 16, 2009 1:35 PM
>> To: ICF.WG.Schemas
>> Subject: [ICF.WG.Schemas] Re: Towards a claims language
>>
>> Drummond, right after you jumped off the call, there was a bit more
>> conversation about this. The general feeling was that the
>> "substring to the left of the ?" idea wasn't robust enough and that
>> we need something better. Sounds like JohnB is going to work on
>> this within the "OASIS Coordination TC". Seems like Mike[rosoft]
>> has some ideas too. And then there's XDI RDF as an option.
>>
>> --Paul
>>
>> On 3/16/09 4:26 PM, "Drummond Reed" <Drummond.R...@parityinc.net>
>> wrote:
>> Paul, RE the second topic below ("dynamic claims"), I'll note
>> something I've mentioned before - I think the path we're on with
>> claims is inevitably going to lead for the need for a "claims
>> language" - a standard means of requesting and composing claims
>> that both IPs, RPs, and selectors can understand.
>>
>> I know it's a big leap from the "flat" claims space we have today.
>> And I agree it makes sense to make a first step towards a claims
>> language by supporting a dynamic payload such as can be passed in a
>> URI query parameter. However the ultimate challenge with this
>> approach is that, as with conventional URI architecture, everything
>> in the query remains opaque to the IP and the selector - it is all
>> RP-specific.
>>
>> For instance, in the example Paul gives...
>>
>> http://schemas.informationcard.net/@ics/transaction/2009-3?amount=29
>> ....
>>
>> ...the "amount" and "currency" parameters are opaque to the
>> selector and IP. This means even though the selector and IP can
>> "understand" that this claim represents a transaction, neither can
>> add further value to the user in processing such a transaction
>> request (such as automatically creating/keeping a digital receipt
>> of this transaction for the user, or automatically warning the user
>> that the requested transaction amount is above their current bank
>> balance).
>>
>> XDI RDF (http://wiki.oasis-open.org/xdi/XdiRdfModel) is one example
>> of what a standardized claims language might look like. It is still
>> young but I believe it meets the key requirements.
>>
>> =Drummond
>>
>> ________________________________
>>
>> From: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com
>> ] On Behalf Of Paul Trevithick
>> Sent: Monday, March 16, 2009 10:28 AM
>> To: ICF.WG.Schemas
>> Subject: [ICF.WG.Schemas] Agenda for the ICF.Schema call today
>>
>> Logistics
>>
>> * 2:30pm Eastern
>> * +1-641-715-3200 / 1024-634#
>>
>> Agenda
>>
>> 1. Use cases for RPs asking for UN/PW.
>>
>> At the end of last weeks call we had compiled this list:
>>
>> 1. HTML forms-based un/pw legacy website (e.g. Amazon.com)
>> 2. Site installs an i-card RP façade/proxy that is expecting a
>> token that in turn contains a un/pw pair
>>
>> [This is background work towards defining some username & password-
>> related claims].
>>
>> 2. Dynamic claims.
>>
>> A number of use cases have arisen where we want/need to be able to
>> convey claim values to the selector. Axel Nennker has suggested a
>> general purpose mechanism for doing this:
>>
>> * The selector matches on everything to the left of the "?" in
>> the claim URI (ignoring everything to the right of it)
>> * The selector passes the entire URI in the RST
>>
>> A very pressing specific use case is the need for an RP to be able
>> to convey a transaction amount. We'd like to use something like
>> this claim:http://schemas.informationcard.net/@ics/transaction/2009-3?
>> amount=29.95 & currency=usd
>>
>> [This WG is the wrong place to define interoperability-related
>> selector features such as is described above. But this WG is the
>> right place to motivate the need for such a thing; we simply can't
>> propose the claim's we'd like to for certain use cases (payment, un/
>> pw, etc.) without support for the above feature. ]
>>
>> --Paul
> >

[Paul Trevithick]

Axel and John,

I’m VERY excited to get this conversation going, getting PayPal & Sid involved, etc. There are two places it could be done:

1. OASIS Coordination WG
2. Browser Integration WG
   

If we rename and expand the scope of #2 to “Web Integration” then I think that would be a better place to do this. Why? Cuz there’s an IPR policy. Besides the output WILL be an input to some SDO (as per our charter). And that’s 90% likely to be OASIS.

--Paul

[John Bradley]

Paul,

I prefer doing this under an IPR policy.   That could also be added to the OASIS WG if desired.

The changes we will contemplating reach to the core of information cards.

If we are going to re-scope the WG to move from browser/selector integration to include all RP, selector and STS issues are there issues with the IPR policy that existing WG members have agreed to?

I know that at OASIS changing the scope of a TC requires the agreement of all the members because of the change in IPR scope.

If we do that we should probably collapse the two WGs together.   It isn't like any of us have extra bodies to split between the groups.

So given that there are no IPR issues with the re-scoping I would be in favor of merging the two WG.

John Bradley

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

[Drummond Reed]

+1 to merging the two groups so we have one place where ICF members are working on input meant to go to the IMI TC. Don’t know what to call the merged group though. The Selector WG?

 

=Drummond

 

---

[Drummond Reed]

+1 to merging the two groups so we have one place where ICF members are working on input meant to go to the IMI TC. Don’t know what to call the merged group though. The Selector WG?

 

=Drummond

 

---

From: icf-wg...@googlegroups.com [mailto:icf-wg...@googlegroups.com] On Behalf Of John Bradley

Sent: Tuesday, March 17, 2009 7:58 AM
To: icf-wg-...@googlegroups.com
Cc: icf-wg...@groups.google.com

[Paul Trevithick]

+1. I propose “Selector Interoperability WG”. That should cover anything that the selector touches. Which is RPs, IdPs and the person’s device.

Let’s move/restart this conversation to the ICF.All list. BTW, we’re going to need a board vote to change scope & merge these two WGs.

[Paul Trevithick]

Agreed on all points. See my email to ICF.All just now.

[Mike Jones]

The cleanest way to pass parameters from the RP to the IdP than the query string approach is probably through WS-SecurityPolicy statements.  WS-SecurityPolicy is extensible, and so new statements for this purpose could be added.

 

Another possibility is using the existing optional ClaimValue element.  ClaimValue is an optional field, and required claims are specified in the RP’s security policy.

 

So, for example, RP’s policy can indicate a required claim as:

ClaimType = AuthorizationAmount

ClaimValue = $19.99  

 

as opposed to simply:

ClaimType = AuthorizationAmount

 

In any event, I believe that we should be looking at this problem through the lens of WS-SecurityPolicy statements – not hacks like query string values in claim type URIs.

 

                                                                Cheers,

                                                                -- Mike