New name for Claims Broker WG?
Paul Trevithick
http://wiki.idcommons.net/Claims_Broker_Charter
Please reply with your preference:
#1: claims broker
#2: claims agent
#3: claims selector
#4: claims service
#5: claims aggregator
#6: something else???
If you don't speak up now, the new WG will start life using "claims broker" until the WG itself decides to rename it.
--Paul
Dave Kearns
-dave
Mary Ruddy
I also prefer “claims agent”
--
General mailing list for Information Cards, the Information Card Foundation, and open identity infrastructure. For more information, visit http://informationcard.net
To post to this group, send email to icf-co...@googlegroups.com
To unsubscribe from this group, send email to
icf-communit...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/icf-community?hl=en
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1191 / Virus Database: 1435/3346 - Release Date: 12/29/10
Dick Hardt
Brady Brim-DeForest
Sent from my iPhone
I vote for #4.
The words "broker" and "agent" have some potential negative connotations. Selector could be confusing, as to purpose. Service means service. Aggregator could offer some confusion with feeds and such, or just be too confusing..
Thus my vote for #4.
--Dean
Please reply with your preference: #1: claims broker #2: claims agent #3: claims selector #4: claims service #5: claims aggregator #6: something else??? If you don't speak up now, the new WG will start life using "claims broker" until the WG itself decides to rename it. --Paul____________________________________________________________ You received this message as a subscriber on the list: stew...@lists.idcommons.net To be removed from the list, send any message to: stewards-u...@lists.idcommons.net For all list information and functions, see: http://lists.idcommons.net/lists/info/stewards
____________________________________________________________
You received this message as a subscriber on the list:
stew...@lists.idcommons.net
To be removed from the list, send any message to:
stewards-u...@lists.idcommons.net
For all list information and functions, see:
http://lists.idcommons.net/lists/info/stewards
Susan Morrow
-----Original Message-----
From: icf-co...@googlegroups.com [mailto:icf-co...@googlegroups.com]
--Paul
--
John Bradley
On 2010-12-30, at 1:40 PM, Ben Laurie wrote:
> On 30 December 2010 13:25, John Bradley <ve7...@ve7jtb.com> wrote:
>> Interesting point.
>>
>> Pauls charter seems to want to cover everything from RP based discovery through cloud based agents to smart clients.
>>
>> I am assuming that part of this is to find a home for u-prove via cloud and smart client selectors.
>>
>> While it is a good idea to minimize the number of people who can see the claim values, one of the things the privacy community wants is for the user to be able to inspect the values returned at the time of release.
>
> Of course.
>
>> That requires a cloud based service to be able to be able to get a display token of some sort.
>
> If I understand you correctly then there are at least two reasons I'd
> object to this:
>
> 1. All a cloud-based service should be offering is storage, in
> general. The actual exercise of tokens should be done on the client.
Several of the WG tasks involve cloud based selectors without any client component.
>
> 2. "Display tokens" are, AIUI, some kind of alleged representation of
> the actual claim to be shown to the user. I fail to see the utility of
> such things for users - the user should just have his client display
> the actual token. Of course they're very useful for everyone else:
> they allow them to lie to the user about what information they are
> exchanging.
It depends on who is creating the token and if it needs to be encrypted end to end.
A client may not be able to see the values of the claims in a token that was created by a issuer.
Also the client needs to be much smarter about how to interpret and display the data if it is not formatted for display.
If this is some "Cloud" selector service like avoco then they get to see the info in ether case.
>
>>
>> I agree that if one of the things the WG is developing is a RP broker service like RPX then it would be best if that intermediary could not inspect the token.
>> Though I prefer to clearly distinguish that RP controlled scenario from the other user centric ones. (the RP based one is not bad just different)
>
> I am not sure what you mean by an "RP broker service".
It is Paul's use case. This would be some service run by the RP or someone on behalf of the RP like JainRain RPXnow that would provide a interface for the user to select Identity providers/claims. I think of this as being more like a broker aggregator service for the RP and not a user service.
We are trying to train users not to give primary credentials to RP. I think having a RP service that looks like it is the users could be a step backwards.
John B.
>>
>> John B
>>
>> On 2010-12-30, at 8:52 AM, Ben Laurie wrote:
>>
>>> I don't have much to say on the name, but I am curious that the
>>> charter does not include privacy w.r.t. the claims themselves (that
>>> is, a service which handles claims on behalf of the user should not be
>>> able to see those claims unless absolutely necessary).
Anthony Nadalin
-----Original Message-----
From: icf-co...@googlegroups.com [mailto:icf-co...@googlegroups.com] On Behalf Of Paul Trevithick
Sent: Wednesday, December 29, 2010 1:40 PM
To: stew...@lists.idcommons.net
Cc: icf-co...@googlegroups.com
Subject: [ICF-Community] New name for Claims Broker WG?
--Paul
--
John Bradley
John B.
Anthony Nadalin
Charles Andres
The real world analogy used is typically a real estate transaction where both buyer and seller have 'agents'. 3rd party: seller's agent 4th party: buyer's agent.
In real estate, there are significant differences between agents and brokers with most states requiring licenses for each regulating their respective activities.
A real estate agent facilitates transactions on behalf of the broker. The agent works under the broker's guidance and legal protection for real estate transactions. Brokers rarely engage in real estate transactions personally.
Agents work for a broker. The broker is the boss of the real estate company or brokerage. This is to limit lawsuits and legal liability against individual agents and offer the protection of a company legal umbrella against frivolous lawsuits and complaints.
We are rapidly building digital agent/avatars that are inexpensive enough to replace the human 3rd and 4th party roles necessary to transform a B2C experience into a higher bandwidth B2B-like experience for every consumer transaction. The real estate paradigm is one of the few B2C transactions with enough money and legal ramifications to make 3rd and 4th party human agents viable. Hence, it is a reasonably good paradigm to consider while we create this new ontology.
Hope this helps,
- Charles
John Bradley
It isn't my WG. I started this by saying the name didn't indicate a user centric goal.
It has been pointed out that some of the scope may be RP related.
I should have said unmodified browser. I think that is what Craig and Paul have referred to.
I agree that there is probably a middle ground between Microsoft Cardspace based on WS-* and nothing at all.
I happend to like Cardspace (RIP) though it was missing some things I thought were important.
I think the current anti thick client trend comes from people looking at the explosion of mobile and not seeing a way to address all of the possible platforms.
I agree that with some basic improvements to browsers we could greatly improve the situation.
However I don't know that that is in scope for this charter?
John B.
On 2010-12-30, at 2:45 PM, Ben Laurie wrote:
> On 30 December 2010 17:03, John Bradley <ve7...@ve7jtb.com> wrote:
>>
>> On 2010-12-30, at 1:40 PM, Ben Laurie wrote:
>>
>>> On 30 December 2010 13:25, John Bradley <ve7...@ve7jtb.com> wrote:
>>>> Interesting point.
>>>>
>>>> Pauls charter seems to want to cover everything from RP based discovery through cloud based agents to smart clients.
>>>>
>>>> I am assuming that part of this is to find a home for u-prove via cloud and smart client selectors.
>>>>
>>>> While it is a good idea to minimize the number of people who can see the claim values, one of the things the privacy community wants is for the user to be able to inspect the values returned at the time of release.
>>>
>>> Of course.
>>>
>>>> That requires a cloud based service to be able to be able to get a display token of some sort.
>>>
>>> If I understand you correctly then there are at least two reasons I'd
>>> object to this:
>>>
>>> 1. All a cloud-based service should be offering is storage, in
>>> general. The actual exercise of tokens should be done on the client.
>>
>> Several of the WG tasks involve cloud based selectors without any client component.
>
> The existing security disaster came about because of a reluctance to
> include the client. Perpetuating it isn't something we should
> sanction.
>
> That said, what WG tasks do not have a client component? AFAICS a
> browser is assumed. A browser is capable of acting as a "client
> component" and, whilst I would be reluctant to see that accepted as a
> final answer, at least without some better support in the browsers, it
> seems like a great way to figure out _what_ should be in the browser.
>
> And browsers are moving towards what is needed to do a good job: local
> storage, JS fast enough to do crypto with and so forth.
>
> Perhaps instead of focusing on getting the whole client built into the
> browser we should figure out what we need beyond what is already
> supported or on the way to being supported in order to be able to
> write secure client components in pure JS/HTML/CSS?
>
>>> 2. "Display tokens" are, AIUI, some kind of alleged representation of
>>> the actual claim to be shown to the user. I fail to see the utility of
>>> such things for users - the user should just have his client display
>>> the actual token. Of course they're very useful for everyone else:
>>> they allow them to lie to the user about what information they are
>>> exchanging.
>>
>> It depends on who is creating the token and if it needs to be encrypted end to end.
>> A client may not be able to see the values of the claims in a token that was created by a issuer.
>> Also the client needs to be much smarter about how to interpret and display the data if it is not formatted for display.
>
> I feel very "so what?" about this argument: if the token needs to be
> end-to-end encrypted (i.e. between the issuer and the RP) then why
> would I, the user, be interested in assisting the transfer of this
> information? Why don't the two parties just talk directly to each
> other? If the stuff is not encrypted then the logic to display it is
> no harder to put at the client end than at the server end.
>
>> If this is some "Cloud" selector service like avoco then they get to see the info in ether case.
>
> Seems like poor planning. Why is that?
John Bradley
I have a previously enjoyed low milage IMI protocol I could let you have, with a nice deployed base in Windows, if you are interested?
No 3rd party disclosure (Not counting Azigo or avoco).
I thought that you don't believe privacy exists. What's one more person with your info?
John B.
Paul Trevithick
Anthony Nadalin
Dick Hardt
From an OpenID point of view, there is no standardization of what a rich client would do. Is that work in scope of this WG? Without that standardized, then having an active client makes little sense for OpenID.
If the big picture objective of the WG is to get user centric identity adopted, I don't think the lack of software is the blocker. Having chatted with all the major browser developers in the past, they all seem interested in implementing support for a protocol if it was clear what they needed to implement and that sites would support it.
I don't want to derail the momentum, but want to check in that the result of the WG will be useful to the big picture vision I think we all share.
-- Dick