Re: SREG's Privacy Policy URL

[Santosh Rajan]

Chris Messina wrote:
> 
> 
> I also think that RP discovery makes a lot of sense, and that really this
> stuff should all live in /host-meta.
> 
> 

Yes I think so too.


-

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com 
-- 
View this message in context: 
http://www.nabble.com/SREG%27s-Privacy-Policy-URL-tp23837076p23845930.html
Sent from the OpenID - Specs mailing list archive at Nabble.com.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: SREG's Privacy Policy URL

[Chris Messina]

I worry a little about dumping this into the UX extension, because it's not
the logical place to look for it.
Instead (and our WG process is really effed here), perhaps we should have a
Policy Expression Extension (acronym pending) so that we could express
things like this:



xri://$xrds*simple




http://schemas.openid.net/policies/privacy
http://example.com/privacy.php






http://schemas.openid.net/policies/terms
http://example.com/terms_and_conditions.php





I also think that RP discovery makes a lot of sense, and that really this
stuff should all live in /host-meta.

Chris

On Tue, Jun 2, 2009 at 11:14 AM, Allen Tom  wrote:

> OK, how about if we define a new Privacy Policy  for RPs to
> include in their XRDS, with a link to their privacy policy?
>
> So the RP would just include the following snippet in its discovery
> document, discoverable under its realm:
>
> 
>  http://specs.openid.net/path/to/privacy/policy
>  http://www.relyingparty.com/path/to/privacy/policy.html
> 
>
> I'm not sure where we can formally document this. I guess we can put it in
> the UI spec?
>
> Allen
>
>
>
>
> George Fletcher wrote:
>
>> I think for a short-term solution we'd need to define service "types" for
>> the privacy policy and TOS for XRDS.
>>
>> For the long-term, the same could potentially be used as "rel" values in
>> the XRD markup. The XRD spec is solidifying but is not 100% stable.
>>
>> I think we should have a discovery option regardless of whether we update
>> UX or AX. So I'd like to see a proposal for XRDS and then when XRD is
>> available, supporting that.
>>
>> Thanks,
>> George
>>
>> Allen Tom wrote:
>>
>>> Hi Luke,
>>>
>>> Yes, this is what we're looking for. Currently, in OpenID, the only way
>>> for the RP to link to its privacy policy (which is sort of like linking to
>>> its ToS) is by passing it in the openid.sreg.policy_url parameter using
>>> SREG.
>>>
>>> Since we're trying to deprecate SREG, we can try to move this parameter
>>> to either the UI or AX Extension, or move it into Discovery.
>>>
>>> Is there an actual Discovery spec?
>>>
>>> Allen
>>>
>>>
>>> Luke Shepard wrote:
>>>
 FWIW, Facebook Connect allows relying parties to define a “terms of
 service” url. We then show that link to users when they click on it. With
 OpenID, the equivalent URL would be set using relying party discovery. Is
 this more or less what you’re looking for?

 Screenshot:




 On 6/2/09 10:21 AM, "Allen Tom"  wrote:


Alternatively, the RP could publish its privacy policy in its
discovery
document, which does make a lot of sense, but I understand that
there's
a lot of work going on to define the next generation of
discovery, and
I'm not quite sure what the timeframe is for that.


>>> 
>>>
>>> ___
>>> specs mailing list
>>> specs@openid.net
>>> http://openid.net/mailman/listinfo/specs
>>>
>>>
>>
>>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>



-- 
Chris Messina
Open Web Advocate

Website: http://factoryjoe.com
Blog: http://factoryjoe.com/blog
Twitter: http://twitter.com/chrismessina

Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] bloggable[X] ask first   [ ] private
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Some suggestions about Open Id AX profile

[Allen Tom]

Hi David,

There has been a lot of discussion about adding Attribute Metadata to AX 
2.0, and this is within the charter of the proposed AX 2.0 Working Group.


http://wiki.openid.net/OpenID_Attribute_Exchange_Extension_2_0

One of the primary use cases driving this is to enable an OP to describe 
the user's email address. For instance, an email address returned via AX 
could just be a user-entered string that is totally unverified, or the 
email address could have been verified by the OP at some point in the 
past. A third option is that the OP is actually the user's email 
provider, and knows with 100% certainty that the user's email address is 
correct.


However, Trust is out of scope for AX 2.0. The RP would have to already 
trust the OP to make claims about the validity of the user's attributes.


The Contract Exchange WG is might be addressing your issue. I'm not 
quite sure what the status is on CX.

http://wiki.openid.net/Working_Groups%3AContract_Exchange_1

Allen


David Garcia wrote:
My company is starting a new Identity Management Service and we want 
to built it's AX interface over OpenId AX profile.


I'll introduce myself at the very beginning. My name is Dave Garcia 
and I'm working in a startup named Tractis in Spain. We have been 
offering online contracts using digital signatures for some years.  We 
want to allow users to use third OPs to login in our site and we want 
to become an OP too.


Also we want to offer identity services some of them using attribute 
exchange.  We are dealing with attributes being asserted by users and 
other are being certified by third parties (inside assertions, 
X509certificates...). We want to make a difference between attributes 
being asserted and those certified the same way authentication methods 
have different assurance levels PAPE profile.


Please let me paste here the briefing of what I'm talking about.

Disclaimer : the following document is in a very early stage, comments 
and suggestions are highly welcome.


Many thanks for everybody reading :)

Dave


  Short briefing for certified-AX profile for OpenId


  Abstract

Openid AX profile for openid provides a way to exchange attributes 
between relying parties and OP. Those attributes are simple key-value 
where the keys are commonly agreed identifiers and values are encoded 
strings. This approach works fine when dealing with "alegated 
attributes" like email, name ... but a problem arises when we need to 
trust this information ("certified attributes").


There are some services that works fine using alegated identities but 
some specially sensitive services, such as banking, don't. In these 
sensitive scenarios, we need to ensure the quality/trustworthiness of 
those attributes. Making a parallelism with existing open specs we 
need to apply mechanisms analogous to those defined on the PAPE for OP 
authentication but for attribute exchange.


From out point of view, and regarding to this existent needs, it would 
be nice to have those attributes scored using a commonly defined 
criteria so when OP returns a certain set of attributes relying party 
could trust them according to the score that OP gave them.



Motivations

Openid is moving towards being the de facto standard for 
authentication on the web. There are some other solutions to deal with 
attributes but it would be nice to have a single technology, empowered 
by the use of their plugins, to deal with identity.



Scenario

Here we'll expose an example of the messages exchanged during 
certificate attributes fetching.



Fetch


  Relying party

openid.ns.ax=http://openid.net/srv/ax/1.0 #To be redefined if a new 
release of the protocol is created


openid.ax.mode=fetch_request

openid.ax.type.age=http://axschema.org/birthDate

openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41


  OpenidProvider

openid.ns.ax=http://openid.net/srv/ax/1.0 openid.ax.mode=fetch_response

openid.ax.type.age=http://axschema.org/birthDate

openid.ax.value.age=23

*openid.ax.score.age=3*

*openid.ax.receipt = #Some kind of receipt certifying the methods used 
to certify the attribute and that could be used for further processes*


openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41


Store

In our approach OP deals with attribute certification processes : 
validating certificates, contacting with attribute certification 
authorities ... so there's no sense to allow the store of attributes 
from others than OP.


Store is applied only to non certified attributes, this is score 0.


What are scores

Scores works in the same way PAPE levels does. They measure the way 
attributes are certified and how the data being certified have been 
collected.


For example: attributes that have been gathered from a /qualified 
certificate/ (according to EU Directive on electronic Signatures) that 
is stored inside a SSCD the score will be 4 (means high). On the other 
hand, a name that has been aleg

Re: SREG's Privacy Policy URL

[Luke Shepard]

+1 RP discovery. If something is likely to persist beyond the active request, 
then it shouldn't be in the request necessarily.

RP discovery would allow, for instance, an OP to show a page of all RPs a user 
has connected to, and links to their respective privacy policies. They can 
model the OP as a single database row with a "privacy_url" field, instead of 
having to keep track of a different url for every user, when in fact that are 
largely the same thing.

I like the "service" suggestion as made below. I'm worried about spoiling the 
simplicity of the UX extension by making it a "kitchen sink" when CX or even 
PAPE is more appropriate. From an engineering perspective, it seems this 
belongs in a simple RP discovery spec. There are other nice things like RP 
images and nice display names that would be nice to include.

Also, curious: what's the process for rolling extensions back into revs of the 
main spec? It will become weird that "return_to" discovery is in the spec but 
this isn't.

On 6/2/09 11:44 AM, "Allen Tom"  wrote:

The internationalization problem is one of the reasons why it might make more 
sense for the privacy policy url to be passed in as a parameter by the RP. The 
RP already is passing the user's language to the OP as part of the UI 
extension, so we could just make this an additional parameter.

Alternatively, we can just say that the RP has a single privacy policy url, and 
the Privacy Polocy URL can take an optional openid.ui.lang parameter. The 
privacy policy url can be discoverable.

Allen



Andrew Arnott wrote:
Would internationalizing entail the OP getting the URL for the RP's privacy 
policy in the right language?

If so, why not just have one URL and let the RP detect the user agent's 
preferred language? (Yes, I know the UI extension has this for the reason that 
the user agent isn't properly configured, so it's an interesting point...)
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your 
right to say it." - S. G. Tallentyre



On Tue, Jun 2, 2009 at 11:24 AM, Johannes Ernst http://openid.net> @netmesh.us  > wrote:

Is there a way this can be internationalized?



On Jun 2, 2009, at 11:14, Allen Tom wrote:


OK, how about if we define a new Privacy Policy  for RPs to include in 
their XRDS, with a link to their privacy policy?

So the RP would just include the following snippet in its discovery document, 
discoverable under its realm:


http://specs.openid.net/path/to/privacy/policy
http://www.relyingparty.com/path/to/privacy/policy.html


I'm not sure where we can formally document this. I guess we can put it in the 
UI spec?

Allen



George Fletcher wrote:

I think for a short-term solution we'd need to define service "types" for the 
privacy policy and TOS for XRDS.

For the long-term, the same could potentially be used as "rel" values in the 
XRD markup. The XRD spec is solidifying but is not 100% stable.

I think we should have a discovery option regardless of whether we update UX or 
AX. So I'd like to see a proposal for XRDS and then when XRD is available, 
supporting that.

Thanks,
George

Allen Tom wrote:

Hi Luke,

Yes, this is what we're looking for. Currently, in OpenID, the only way for the 
RP to link to its privacy policy (which is sort of like linking to its ToS) is 
by passing it in the openid.sreg.policy_url parameter using SREG.

Since we're trying to deprecate SREG, we can try to move this parameter to 
either the UI or AX Extension, or move it into Discovery.

Is there an actual Discovery spec?

Allen


Luke Shepard wrote:

FWIW, Facebook Connect allows relying parties to define a "terms of service" 
url. We then show that link to users when they click on it. With OpenID, the 
equivalent URL would be set using relying party discovery. Is this more or less 
what you're looking for?

Screenshot:




On 6/2/09 10:21 AM, "Allen Tom"  wrote:


  Alternatively, the RP could publish its privacy policy in its
  discovery
  document, which does make a lot of sense, but I understand that
  there's
  a lot of work going on to define the next generation of
  discovery, and
  I'm not quite sure what the timeframe is for that.





___
specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs





___
specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs


___
specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs









___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Some suggestions about Open Id AX profile

[SitG Admin]

In Openid attributes are alegated, so you don't have to trust the OP 
because there's nothing to trust on. Dealing with certified 
attributes create a problem : how could I, as a relying party, know 
that this OP works fine and if it says "level 4" all criteria to 
consider were done the right way.


You can't. But you have the right idea:

Our proposal, in the same way as PAPE, the Relying Party does not 
need to trust the OP. The User is the one that needs to trust the 
OP. If problems arises with certain OP, then relying parties could 
choose to use some OP and exclude others with mechanisms like 
white/black lists.


The user needs to trust the OP that the *other* user (the one they 
have a contract with) is using; so, share that information, and 
displace the responsibility for distrusting various claims onto the 
user. This isn't very *friendly*, mind you, but I don't see any way 
of preventing a user from setting up an absolutely new OP just for 
that one contract; with a valuable enough contract at stake, it would 
even be cost-effective to rig one's own "independent auditors".


You might be able to score OP's locally, by "how many other contracts 
have trusted this OP", but then (to prevent gaming the system) there 
should be other statistics such as how long the OP has been in use, 
how often a contract has required "use another OP" during 
renegotiation, how often negotiations have *failed* entirely because 
one party refused to use another OP, the demographic spread of these 
uses over time, and maybe even the values of those contracts (for 
low-value contracts, there might not have been as much scrutiny over 
the trustworthiness of OP's), most or all of which raises user 
privacy issues. The last item raises verifiability issues; how do you 
*know* the value of the contracts are as reported?


-Shade
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: SREG's Privacy Policy URL

[SitG Admin]

Would internationalizing entail the OP getting the URL for the RP's 
privacy policy in the right language?


If so, why not just have one URL and let the RP detect the user 
agent's preferred language? (Yes, I know the UI extension has this 
for the reason that the user agent isn't properly configured, so 
it's an interesting point...)


How about the Privacy Policy itself containing pointers to other versions?

Not just languages, but perhaps machine-readable XRD files, as well?




irrevocable
perpetual
nontransferrable

And so on, perhaps with a link to some common documentation defining 
the usual meaning of all these terms.


-Shade
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: SREG's Privacy Policy URL

[John Bradley]

I think this is covered in http negotiation.

If the OP knows the users language preference from there profile they  
can fetch the correct one for the user and display it.


Can google stop changing my language pregrence to Spanish?

I think a single URI for each policy and letting http deal with the  
language issue is best.


For process we could have it written up in the XRI TC as a profile for  
XRDS (Breno/George?),  or attempt to spin up a OIDF WG.


I don't think it would be more than a page ether way.

The other alternative is to agree on it as a community and RP's just  
start publishing it.


It isn't like we haven't done that in the past.   SREG was never  
adopted as a standard.


John B.

On 2-Jun-09, at 2:28 PM, specs-requ...@openid.net wrote:


Date: Tue, 2 Jun 2009 11:27:44 -0700
From: Andrew Arnott 
Subject: Re: SREG's Privacy Policy URL
To: Johannes Ernst 
Cc: OpenID Specs Mailing List 
Message-ID:
<216e54900906021127r11597727t965b1e8ecad57...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary=001e680f11ec14b6d2046b61b46c

--001e680f11ec14b6d2046b61b46c
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Would internationalizing entail the OP getting the URL for the RP's  
privacy

policy in the right language?

If so, why not just have one URL and let the RP detect the user  
agent's
preferred language? (Yes, I know the UI extension has this for the  
reason

that the user agent isn't properly configured, so it's an interesting
point...)
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the  
death

your right to say it." - S. G. Tallentyre





smime.p7s
Description: S/MIME cryptographic signature
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: SREG's Privacy Policy URL

[Andrew Arnott]

Whether we go for passing a parameter or not, I like the idea of (also)
having RP discovery offer a URL as well so that unsolicited assertions from
OPs can show the privacy policy to the user.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre


On Tue, Jun 2, 2009 at 11:44 AM, Allen Tom  wrote:

>  The internationalization problem is one of the reasons why it might make
> more sense for the privacy policy url to be passed in as a parameter by the
> RP. The RP already is passing the user's language to the OP as part of the
> UI extension, so we could just make this an additional parameter.
>
> Alternatively, we can just say that the RP has a single privacy policy url,
> and the Privacy Polocy URL can take an optional openid.ui.lang parameter.
> The privacy policy url can be discoverable.
>
> Allen
>
>
>
> Andrew Arnott wrote:
>
> Would internationalizing entail the OP getting the URL for the RP's privacy
> policy in the right language?
>
> If so, why not just have one URL and let the RP detect the user agent's
> preferred language? (Yes, I know the UI extension has this for the reason
> that the user agent isn't properly configured, so it's an interesting
> point...)
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
> On Tue, Jun 2, 2009 at 11:24 AM, Johannes Ernst  netmesh.us> wrote:
>
>> Is there a way this can be internationalized?
>>
>> On Jun 2, 2009, at 11:14, Allen Tom wrote:
>>
>>  OK, how about if we define a new Privacy Policy  for RPs to
>>> include in their XRDS, with a link to their privacy policy?
>>>
>>> So the RP would just include the following snippet in its discovery
>>> document, discoverable under its realm:
>>>
>>> 
>>> http://specs.openid.net/path/to/privacy/policy
>>> http://www.relyingparty.com/path/to/privacy/policy.html
>>> 
>>>
>>> I'm not sure where we can formally document this. I guess we can put it
>>> in the UI spec?
>>>
>>> Allen
>>>
>>>
>>>
>>> George Fletcher wrote:
>>>
 I think for a short-term solution we'd need to define service "types"
 for the privacy policy and TOS for XRDS.

 For the long-term, the same could potentially be used as "rel" values in
 the XRD markup. The XRD spec is solidifying but is not 100% stable.

 I think we should have a discovery option regardless of whether we
 update UX or AX. So I'd like to see a proposal for XRDS and then when XRD 
 is
 available, supporting that.

 Thanks,
 George

 Allen Tom wrote:

> Hi Luke,
>
> Yes, this is what we're looking for. Currently, in OpenID, the only way
> for the RP to link to its privacy policy (which is sort of like linking to
> its ToS) is by passing it in the openid.sreg.policy_url parameter using
> SREG.
>
> Since we're trying to deprecate SREG, we can try to move this parameter
> to either the UI or AX Extension, or move it into Discovery.
>
> Is there an actual Discovery spec?
>
> Allen
>
>
> Luke Shepard wrote:
>
>> FWIW, Facebook Connect allows relying parties to define a “terms of
>> service” url. We then show that link to users when they click on it. With
>> OpenID, the equivalent URL would be set using relying party discovery. Is
>> this more or less what you’re looking for?
>>
>> Screenshot:
>>
>>
>>
>>
>> On 6/2/09 10:21 AM, "Allen Tom"  wrote:
>>
>>
>>   Alternatively, the RP could publish its privacy policy in its
>>   discovery
>>   document, which does make a lot of sense, but I understand that
>>   there's
>>   a lot of work going on to define the next generation of
>>   discovery, and
>>   I'm not quite sure what the timeframe is for that.
>>
>>
>
> 
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>

>>> ___
>>> specs mailing list
>>> specs@openid.net
>>> http://openid.net/mailman/listinfo/specs
>>>
>>
>> ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>
> --
>
> ___
> specs mailing listsp...@openid.nethttp://openid.net/mailman/listinfo/specs
>
>
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: SREG's Privacy Policy URL

[Allen Tom]

The internationalization problem is one of the reasons why it might make 
more sense for the privacy policy url to be passed in as a parameter by 
the RP. The RP already is passing the user's language to the OP as part 
of the UI extension, so we could just make this an additional parameter.


Alternatively, we can just say that the RP has a single privacy policy 
url, and the Privacy Polocy URL can take an optional openid.ui.lang 
parameter. The privacy policy url can be discoverable.


Allen



Andrew Arnott wrote:
Would internationalizing entail the OP getting the URL for the RP's 
privacy policy in the right language?


If so, why not just have one URL and let the RP detect the user 
agent's preferred language? (Yes, I know the UI extension has this for 
the reason that the user agent isn't properly configured, so it's an 
interesting point...)

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the 
death your right to say it." - S. G. Tallentyre



On Tue, Jun 2, 2009 at 11:24 AM, Johannes Ernst @netmesh.us > wrote:


Is there a way this can be internationalized?


On Jun 2, 2009, at 11:14, Allen Tom wrote:

OK, how about if we define a new Privacy Policy  for
RPs to include in their XRDS, with a link to their privacy policy?

So the RP would just include the following snippet in its
discovery document, discoverable under its realm:


http://specs.openid.net/path/to/privacy/policy
http://www.relyingparty.com/path/to/privacy/policy.html


I'm not sure where we can formally document this. I guess we
can put it in the UI spec?

Allen



George Fletcher wrote:

I think for a short-term solution we'd need to define
service "types" for the privacy policy and TOS for XRDS.

For the long-term, the same could potentially be used as
"rel" values in the XRD markup. The XRD spec is
solidifying but is not 100% stable.

I think we should have a discovery option regardless of
whether we update UX or AX. So I'd like to see a proposal
for XRDS and then when XRD is available, supporting that.

Thanks,
George

Allen Tom wrote:

Hi Luke,

Yes, this is what we're looking for. Currently, in
OpenID, the only way for the RP to link to its privacy
policy (which is sort of like linking to its ToS) is
by passing it in the openid.sreg.policy_url parameter
using SREG.

Since we're trying to deprecate SREG, we can try to
move this parameter to either the UI or AX Extension,
or move it into Discovery.

Is there an actual Discovery spec?

Allen


Luke Shepard wrote:

FWIW, Facebook Connect allows relying parties to
define a “terms of service” url. We then show that
link to users when they click on it. With OpenID,
the equivalent URL would be set using relying
party discovery. Is this more or less what you’re
looking for?

Screenshot:




On 6/2/09 10:21 AM, "Allen Tom"
mailto:a...@yahoo-inc.com>>
wrote:


  Alternatively, the RP could publish its privacy
policy in its
  discovery
  document, which does make a lot of sense, but I
understand that
  there's
  a lot of work going on to define the next
generation of
  discovery, and
  I'm not quite sure what the timeframe is for that.





___
specs mailing list
specs@openid.net 
http://openid.net/mailman/listinfo/specs



___
specs mailing list
specs@openid.net 
http://openid.net/mailman/listinfo/specs


___
specs mailing list
specs@openid.net 
http://openid.net/mailman/listinfo/specs




___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
  


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/spe

Re: SREG's Privacy Policy URL

[John Bradley]

The XRDS discovery spec is defined by the XRI 2.0 spec as profiled by  
Yadis.


There is a new discovery spec that converges XRDS Simple as used in  
oAuth,  Yadis and XRI.


That is the XRD 1.0 spec currently under development in the XRI TC at  
OASIS.


There will need to be a profile of the discovery spec as part of  
openID 2.1 if that is desired.


Google, Yahoo and others are contributing the XRD spec.

There are references in openID 2.0 and the extensions on what needs to  
go in to a XRDS,  but there is no comprehensive profile of XRDS  for  
openID that defines where new Services or extension elements are added.


I agree that communicating RP TOS and Privacy via RP Discovery is a  
likely candidate.


The CX (contract exchange) workgroup is also looking at some of the  
same issues where those policies need to be signed by the user.


I know that is a requirement in Europe for accessing government sites,  
from my conversations with the people from the STORK initiative.

http://www.eid-stork.eu/

We may need lightweight  policy display and the more heavyweight  
signing ability that CX brings to the table to work across all the use  
cases from different jurisdictions.


John B.

On 2-Jun-09, at 1:56 PM, specs-requ...@openid.net wrote:


Date: Tue, 02 Jun 2009 10:55:55 -0700
From: Allen Tom 
Subject: Re: SREG's Privacy Policy URL
To: Luke Shepard , "specs@openid.net"

Message-ID: <4a2567ab.10...@yahoo-inc.com>
Content-Type: multipart/alternative;
boundary="060606030309050004000507"

This is a multi-part message in MIME format.
--060606030309050004000507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Luke,

Yes, this is what we're looking for. Currently, in OpenID, the only  
way
for the RP to link to its privacy policy (which is sort of like  
linking

to its ToS) is by passing it in the openid.sreg.policy_url parameter
using SREG.

Since we're trying to deprecate SREG, we can try to move this  
parameter

to either the UI or AX Extension, or move it into Discovery.

Is there an actual Discovery spec?

Allen


Luke Shepard wrote:

FWIW, Facebook Connect allows relying parties to define a "terms of
service" url. We then show that link to users when they click on it.
With OpenID, the equivalent URL would be set using relying party
discovery. Is this more or less what you're looking for?

Screenshot:








smime.p7s
Description: S/MIME cryptographic signature
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: SREG's Privacy Policy URL

[Andrew Arnott]

Would internationalizing entail the OP getting the URL for the RP's privacy
policy in the right language?

If so, why not just have one URL and let the RP detect the user agent's
preferred language? (Yes, I know the UI extension has this for the reason
that the user agent isn't properly configured, so it's an interesting
point...)
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre


On Tue, Jun 2, 2009 at 11:24 AM, Johannes Ernst  wrote:

> Is there a way this can be internationalized?
>
>
> On Jun 2, 2009, at 11:14, Allen Tom wrote:
>
>  OK, how about if we define a new Privacy Policy  for RPs to
>> include in their XRDS, with a link to their privacy policy?
>>
>> So the RP would just include the following snippet in its discovery
>> document, discoverable under its realm:
>>
>> 
>> http://specs.openid.net/path/to/privacy/policy
>> http://www.relyingparty.com/path/to/privacy/policy.html
>> 
>>
>> I'm not sure where we can formally document this. I guess we can put it in
>> the UI spec?
>>
>> Allen
>>
>>
>>
>> George Fletcher wrote:
>>
>>> I think for a short-term solution we'd need to define service "types" for
>>> the privacy policy and TOS for XRDS.
>>>
>>> For the long-term, the same could potentially be used as "rel" values in
>>> the XRD markup. The XRD spec is solidifying but is not 100% stable.
>>>
>>> I think we should have a discovery option regardless of whether we update
>>> UX or AX. So I'd like to see a proposal for XRDS and then when XRD is
>>> available, supporting that.
>>>
>>> Thanks,
>>> George
>>>
>>> Allen Tom wrote:
>>>
 Hi Luke,

 Yes, this is what we're looking for. Currently, in OpenID, the only way
 for the RP to link to its privacy policy (which is sort of like linking to
 its ToS) is by passing it in the openid.sreg.policy_url parameter using
 SREG.

 Since we're trying to deprecate SREG, we can try to move this parameter
 to either the UI or AX Extension, or move it into Discovery.

 Is there an actual Discovery spec?

 Allen


 Luke Shepard wrote:

> FWIW, Facebook Connect allows relying parties to define a “terms of
> service” url. We then show that link to users when they click on it. With
> OpenID, the equivalent URL would be set using relying party discovery. Is
> this more or less what you’re looking for?
>
> Screenshot:
>
>
>
>
> On 6/2/09 10:21 AM, "Allen Tom"  wrote:
>
>
>   Alternatively, the RP could publish its privacy policy in its
>   discovery
>   document, which does make a lot of sense, but I understand that
>   there's
>   a lot of work going on to define the next generation of
>   discovery, and
>   I'm not quite sure what the timeframe is for that.
>
>
 

 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs


>>>
>> ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: SREG's Privacy Policy URL

[Johannes Ernst]

Is there a way this can be internationalized?

On Jun 2, 2009, at 11:14, Allen Tom wrote:

OK, how about if we define a new Privacy Policy  for RPs to  
include in their XRDS, with a link to their privacy policy?


So the RP would just include the following snippet in its discovery  
document, discoverable under its realm:



http://specs.openid.net/path/to/privacy/policy
http://www.relyingparty.com/path/to/privacy/policy.html


I'm not sure where we can formally document this. I guess we can put  
it in the UI spec?


Allen



George Fletcher wrote:
I think for a short-term solution we'd need to define service  
"types" for the privacy policy and TOS for XRDS.


For the long-term, the same could potentially be used as "rel"  
values in the XRD markup. The XRD spec is solidifying but is not  
100% stable.


I think we should have a discovery option regardless of whether we  
update UX or AX. So I'd like to see a proposal for XRDS and then  
when XRD is available, supporting that.


Thanks,
George

Allen Tom wrote:

Hi Luke,

Yes, this is what we're looking for. Currently, in OpenID, the  
only way for the RP to link to its privacy policy (which is sort  
of like linking to its ToS) is by passing it in the  
openid.sreg.policy_url parameter using SREG.


Since we're trying to deprecate SREG, we can try to move this  
parameter to either the UI or AX Extension, or move it into  
Discovery.


Is there an actual Discovery spec?

Allen


Luke Shepard wrote:
FWIW, Facebook Connect allows relying parties to define a “terms  
of service” url. We then show that link to users when they click  
on it. With OpenID, the equivalent URL would be set using relying  
party discovery. Is this more or less what you’re looking for?


Screenshot:




On 6/2/09 10:21 AM, "Allen Tom"  wrote:


   Alternatively, the RP could publish its privacy policy in its
   discovery
   document, which does make a lot of sense, but I understand that
   there's
   a lot of work going on to define the next generation of
   discovery, and
   I'm not quite sure what the timeframe is for that.





___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs





___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: SREG's Privacy Policy URL

[Andrew Arnott]

I like this idea best.

UI spec, and a future version of the AX spec can mention this.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre


On Tue, Jun 2, 2009 at 11:14 AM, Allen Tom  wrote:

> OK, how about if we define a new Privacy Policy  for RPs to
> include in their XRDS, with a link to their privacy policy?
>
> So the RP would just include the following snippet in its discovery
> document, discoverable under its realm:
>
> 
>  http://specs.openid.net/path/to/privacy/policy
>  http://www.relyingparty.com/path/to/privacy/policy.html
> 
>
> I'm not sure where we can formally document this. I guess we can put it in
> the UI spec?
>
> Allen
>
>
>
>
> George Fletcher wrote:
>
>> I think for a short-term solution we'd need to define service "types" for
>> the privacy policy and TOS for XRDS.
>>
>> For the long-term, the same could potentially be used as "rel" values in
>> the XRD markup. The XRD spec is solidifying but is not 100% stable.
>>
>> I think we should have a discovery option regardless of whether we update
>> UX or AX. So I'd like to see a proposal for XRDS and then when XRD is
>> available, supporting that.
>>
>> Thanks,
>> George
>>
>> Allen Tom wrote:
>>
>>> Hi Luke,
>>>
>>> Yes, this is what we're looking for. Currently, in OpenID, the only way
>>> for the RP to link to its privacy policy (which is sort of like linking to
>>> its ToS) is by passing it in the openid.sreg.policy_url parameter using
>>> SREG.
>>>
>>> Since we're trying to deprecate SREG, we can try to move this parameter
>>> to either the UI or AX Extension, or move it into Discovery.
>>>
>>> Is there an actual Discovery spec?
>>>
>>> Allen
>>>
>>>
>>> Luke Shepard wrote:
>>>
 FWIW, Facebook Connect allows relying parties to define a “terms of
 service” url. We then show that link to users when they click on it. With
 OpenID, the equivalent URL would be set using relying party discovery. Is
 this more or less what you’re looking for?

 Screenshot:




 On 6/2/09 10:21 AM, "Allen Tom"  wrote:


Alternatively, the RP could publish its privacy policy in its
discovery
document, which does make a lot of sense, but I understand that
there's
a lot of work going on to define the next generation of
discovery, and
I'm not quite sure what the timeframe is for that.


>>> 
>>>
>>> ___
>>> specs mailing list
>>> specs@openid.net
>>> http://openid.net/mailman/listinfo/specs
>>>
>>>
>>
>>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: SREG's Privacy Policy URL

[Allen Tom]

OK, how about if we define a new Privacy Policy  for RPs to 
include in their XRDS, with a link to their privacy policy?


So the RP would just include the following snippet in its discovery 
document, discoverable under its realm:



 http://specs.openid.net/path/to/privacy/policy
 http://www.relyingparty.com/path/to/privacy/policy.html


I'm not sure where we can formally document this. I guess we can put it 
in the UI spec?


Allen



George Fletcher wrote:
I think for a short-term solution we'd need to define service "types" 
for the privacy policy and TOS for XRDS.


For the long-term, the same could potentially be used as "rel" values 
in the XRD markup. The XRD spec is solidifying but is not 100% stable.


I think we should have a discovery option regardless of whether we 
update UX or AX. So I'd like to see a proposal for XRDS and then when 
XRD is available, supporting that.


Thanks,
George

Allen Tom wrote:

Hi Luke,

Yes, this is what we're looking for. Currently, in OpenID, the only 
way for the RP to link to its privacy policy (which is sort of like 
linking to its ToS) is by passing it in the openid.sreg.policy_url 
parameter using SREG.


Since we're trying to deprecate SREG, we can try to move this 
parameter to either the UI or AX Extension, or move it into Discovery.


Is there an actual Discovery spec?

Allen


Luke Shepard wrote:
FWIW, Facebook Connect allows relying parties to define a “terms of 
service” url. We then show that link to users when they click on it. 
With OpenID, the equivalent URL would be set using relying party 
discovery. Is this more or less what you’re looking for?


Screenshot:




On 6/2/09 10:21 AM, "Allen Tom"  wrote:


Alternatively, the RP could publish its privacy policy in its
discovery
document, which does make a lot of sense, but I understand that
there's
a lot of work going on to define the next generation of
discovery, and
I'm not quite sure what the timeframe is for that.





___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
  




___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: SREG's Privacy Policy URL

[George Fletcher]

I think for a short-term solution we'd need to define service "types" 
for the privacy policy and TOS for XRDS.


For the long-term, the same could potentially be used as "rel" values in 
the XRD markup. The XRD spec is solidifying but is not 100% stable.


I think we should have a discovery option regardless of whether we 
update UX or AX. So I'd like to see a proposal for XRDS and then when 
XRD is available, supporting that.


Thanks,
George

Allen Tom wrote:

Hi Luke,

Yes, this is what we're looking for. Currently, in OpenID, the only 
way for the RP to link to its privacy policy (which is sort of like 
linking to its ToS) is by passing it in the openid.sreg.policy_url 
parameter using SREG.


Since we're trying to deprecate SREG, we can try to move this 
parameter to either the UI or AX Extension, or move it into Discovery.


Is there an actual Discovery spec?

Allen


Luke Shepard wrote:
FWIW, Facebook Connect allows relying parties to define a “terms of 
service” url. We then show that link to users when they click on it. 
With OpenID, the equivalent URL would be set using relying party 
discovery. Is this more or less what you’re looking for?


Screenshot:




On 6/2/09 10:21 AM, "Allen Tom"  wrote:


Alternatively, the RP could publish its privacy policy in its
discovery
document, which does make a lot of sense, but I understand that
there's
a lot of work going on to define the next generation of
discovery, and
I'm not quite sure what the timeframe is for that.





___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
  


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

부재 중 회신

[canihop]

Hi Friend,
How are you doing recently? I would like to introduce you a very good company which I know. Their website is www.myewell.com. They can offer you all kinds of
Electronic products like laptops, gps,TV LCD,cell phones,ps3,MP3/4, etcPlease take some time to have a check, There must have something you'd like to buy.Their contact email: myew...@vip.188.com 
Hope you have a good mood in shopping from their company!
Best Regards
   Eun-ju님

 ___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Some suggestions about Open Id AX profile

[David Garcia]

My company is starting a new Identity Management Service and we want to
built it's AX interface over OpenId AX profile.

I'll introduce myself at the very beginning. My name is Dave Garcia and I'm
working in a startup named Tractis in Spain. We have been offering online
contracts using digital signatures for some years.  We want to allow users
to use third OPs to login in our site and we want to become an OP too.

Also we want to offer identity services some of them using attribute
exchange.  We are dealing with attributes being asserted by users and other
are being certified by third parties (inside assertions,
X509certificates...). We want to make a difference between attributes being
asserted and those certified the same way authentication methods have
different assurance levels PAPE profile.

Please let me paste here the briefing of what I'm talking about.

Disclaimer : the following document is in a very early stage, comments and
suggestions are highly welcome.

Many thanks for everybody reading :)

Dave

Short briefing for certified-AX profile for OpenIdAbstract

Openid AX profile for openid provides a way to exchange attributes between
relying parties and OP. Those attributes are simple key-value where the keys
are commonly agreed identifiers and values are encoded strings. This
approach works fine when dealing with "alegated attributes" like email, name
... but a problem arises when we need to trust this information ("certified
attributes").

There are some services that works fine using alegated identities but some
specially sensitive services, such as banking, don't. In these sensitive
scenarios, we need to ensure the quality/trustworthiness of those
attributes. Making a parallelism with existing open specs we need to apply
mechanisms analogous to those defined on the PAPE for OP authentication but
for attribute exchange.

>From out point of view, and regarding to this existent needs, it would be
nice to have those attributes scored using a commonly defined criteria so
when OP returns a certain set of attributes relying party could trust them
according to the score that OP gave them.
Motivations

Openid is moving towards being the de facto standard for authentication on
the web. There are some other solutions to deal with attributes but it would
be nice to have a single technology, empowered by the use of their plugins,
to deal with identity.
Scenario

Here we'll expose an example of the messages exchanged during certificate
attributes fetching.
FetchRelying party

openid.ns.ax=http://openid.net/srv/ax/1.0 #To be redefined if a new release
of the protocol is created

openid.ax.mode=fetch_request

openid.ax.type.age=http://axschema.org/birthDate

openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41
OpenidProvider

openid.ns.ax=http://openid.net/srv/ax/1.0 openid.ax.mode=fetch_response

openid.ax.type.age=http://axschema.org/birthDate

openid.ax.value.age=23

*openid.ax.score.age=3*

*openid.ax.receipt = #Some kind of receipt certifying the methods used to
certify the attribute and that could be used for further processes*

openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41
Store

In our approach OP deals with attribute certification processes : validating
certificates, contacting with attribute certification authorities ... so
there's no sense to allow the store of attributes from others than OP.

Store is applied only to non certified attributes, this is score 0.
What are scores

Scores works in the same way PAPE levels does. They measure the way
attributes are certified and how the data being certified have been
collected.

For example: attributes that have been gathered from a *qualified
certificate* (according to EU Directive on electronic Signatures) that is
stored inside a SSCD the score will be 4 (means high). On the other hand, a
name that has been alegated in a web form will have the score 0, means low.

Between 0 and 4 you have all the ways you can certify an attribute from 0
(no certification) to 4. We made a brief definition of the score concept
that you could find here (https://www.tractis.com/tractis_score_policy) and
the mapping to real methods could be found here (
https://www.tractis.com/tractis_score_mapping).
As we indicate in these documents, we (Tractis) have not invented neither
the classification nor the score policy but used previous work by the NIST
and EU.
Problems to be solved

In Openid attributes are alegated, so you don't have to trust the OP because
there's nothing to trust on. Dealing with certified attributes create a
problem : how could I, as a relying party, know that this OP *works* fine
and if it says "level 4" all criteria to consider were done the right way.

Our proposal, in the same way as PAPE, the Relying Party does not need to
trust the OP. The User is the one that needs to trust the OP. If problems
arises with certain OP, then relying parties could choose to use some

SREG's Privacy Policy URL

[Allen Tom]

Hi All,

The Simple Registration Extension provides an interface for the RP to 
pass the OP a link to the RP's privacy policy in the authentication 
request. According to the SREG spec, OPs SHOULD display this URL to the 
End User if it is given.


http://openid.net/specs/openid-simple-registration-extension-1_1-01.html#anchor3

Although Attribute Exchange is intended to be be a superset of SREG, the 
AX 1.0 spec omitted this feature. Some OPs (like Yahoo) believe that 
it's important to link to the RP's privacy policy, so it's unfortunate 
that this parameter was left out of AX. We think it's important that 
there's an automated way for an RP to inform the OP about its privacy 
policy without requiring the RP to pre-register itself with the OP.


Arguably, the RP's privacy policy is relevant even if there's no SREG/AX 
involved, so perhaps it doesn't make sense to require the RP to use 
SREG/AX to pass its privacy policy to the OP.


Given that the intent of the openid.sreg.policy_url parameter in SREG is 
to define an interface for the RP to ask the OP to link to the RP's 
privacy policy on the OP's UI,  it seems that this feature could be 
included in the OpenID User Interace Extension, which is intended to 
allow the RP to influence aspects of the OP's UI.


Alternatively, the RP could publish its privacy policy in its discovery 
document, which does make a lot of sense, but I understand that there's 
a lot of work going on to define the next generation of discovery, and 
I'm not quite sure what the timeframe is for that.


Comments?
Allen

.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs