[OpenID] Building on the OpenID PAPE specification
David Recordon
drecordon at sixapart.com
Tue Oct 14 15:56:35 UTC 2008
I'd be much more supportive of policies like those though I truly
believe the way to influence here is to show that there are OPs and
RPs ready to implement these policies if they became specified. As
Dick has also pointed out, these can be defined as additional policies
beyond those in PAPE and still see adoption that way.
--David
On Oct 8, 2008, at 11:12 AM, Brian Kelly wrote:
> Dick,
>
> I think it would be helpful to define the specific authentication
> methods used as policies within PAPE. We could reduce the number of
> authentication details in the current version of PAPE-AM and come up
> with a list to be included as "authentication method URIs" in PAPE.
> e.g.
>
> PKI algo: http://schemas.openid.net/pape/pki/rsa/1024
> Private key storage: http://schemas.openid.net/pape/pki/hardware-key-nonexportable
> OTP: http://schemas.openid.net/pape/otp/hotp
> Channel Security: http://schemas.openid.net/pape/channel/ssl_ev
>
> To your second point, I would argue that not all OPs are created
> equal. I see the OpenID landscape evolving into a variety of "security
> levels" of OPs and RPs. Do I need an OP that requires a hardware key
> to make a comment on a blog? No. But I do see the value in having a
> "high security" OP to login to my bank account and transfer money.
>
> The need for more-secure OPs is evident by the lack of RP adoption on
> commerce websites. These websites have more risk when it comes to
> compromised accounts. RPs have the right to discriminate which OPs
> they accept. And giving the RPs a framework with which to judge the
> security of OPs should help _increase_ adoption of OpenID.
>
> Brian
>
> On Oct 8, 2008, at 12:47 PM, Dick Hardt wrote:
>
>> Hi Brian
>>
>> All of those points would seem to me to be able to be defined as a
>> general policy with PAPE that could then be used by many RPs and OPs.
>>
>> If your goal is to narrow the number of OPs that can meet an RP's
>> requirements to being OP's that implement a specific technology
>> (yours? :-) -- you are going counter (IMHO) to the objectives of
>> OpenID.
>>
>> -- Dick
>>
>> On 8-Oct-08, at 9:30 AM, Brian Kelly wrote:
>>
>>> Dick,
>>>
>>> A few examples of why an RP might want to know more about what kind
>>> of authentication an OP used:
>>>
>>> 1. RP wants to make sure OP is using reasonable practices for
>>> password strength enforcement (e.g. change PW every 6 months, at
>>> least 8 characters with at least 4 of those characters being unique)
>>>
>>> If an RP is going to be providing access to confidential
>>> information, the RP may want to ensure that their users' OPs are
>>> enforcing reasonable password policies.
>>>
>>> 2. Same issue as in #1, but applied to OTP length / type.
>>>
>>> 3. RP wants to be assured of OP user's identity by verifying that
>>> the user authenticated using a digital certificate that was
>>> provided by specific root CAs that the RP trusts.
>>>
>>> By providing more granular information about how the user was
>>> authenticated, the RP can be assured that the OP's authentication
>>> methods are at least as good as the authentication methods the RP
>>> would have used without OpenID.
>>>
>>> The higher-level goal of PAPE-AM, which is aligned with a goal of
>>> PAPE, is to increase OpenID adoption among RPs that must ensure
>>> that access to services and individual's information is properly
>>> protected by the OP.
>>>
>>> Brian
>>>
>>> On Oct 7, 2008, at 3:03 PM, Dick Hardt wrote:
>>>
>>>> Brian
>>>>
>>>> I can understand why the WG would reject something that was not
>>>> within the charter. The time for you to have gotten involved would
>>>> have been at the creation of the charter. Water under the bridge
>>>> now.
>>>>
>>>> I read over your blog post, but I'm unclear on why an RP *needs*
>>>> to understand the kind of authentication that was used? There is
>>>> a tendency for entities to *want* as much control as possible --
>>>> but I don't follow the logic for why they *need* it. Would you
>>>> elaborate?
>>>>
>>>> -- Dick
>>>>
>>>> On 7-Oct-08, at 6:39 AM, Brian Kelly wrote:
>>>>
>>>>> Dick,
>>>>>
>>>>> When we completed the first draft of PAPE-AM, we sent it to the
>>>>> PAPE specs working group list for input. It was promptly
>>>>> dismissed since it went against the PAPE WG charter, which states
>>>>> that only high-level policies should be included in the spec.
>>>>>
>>>>> At that point the PAPE-AM team decided that it would be a good
>>>>> idea to open the discussion up to the broader OpenID community to
>>>>> seek guidance on next-steps. I encourage the PAPE WG folks to
>>>>> comment on this as well.
>>>>>
>>>>> To your second point about how the RP should not care about how
>>>>> the user was authenticated, I agree that the trust needs to start
>>>>> at the OP. The main issue we were trying to address in PAPE-AM is
>>>>> that there is too much ambiguity in the high level policies as
>>>>> stated in PAPE today. This ambiguity makes it difficult for both
>>>>> OPs and RPs to understand what kind of authentication was
>>>>> actually used.
>>>>>
>>>>> Brian
>>>>>
>>>>> On Oct 6, 2008, at 7:12 PM, Dick Hardt wrote:
>>>>>
>>>>>>
>>>>>> Brian: did you participate in the PAPE spec? That would have
>>>>>> been the place to have brought up this issue.
>>>>>>
>>>>>> Although I did not participate in the PAPE specification (only
>>>>>> so much time) -- I was supportive of the high level policies vs
>>>>>> specific technologies. The RP really does not (well, *should*
>>>>>> not) care about how the user was authenticated, just about how
>>>>>> much certainty the OP has that it is the user. It is the OP
>>>>>> making the assertion after all. Keep in mind I can have an OP
>>>>>> that says that all the factors were used, even if they were not.
>>>>>>
>>>>>> -- Dick
>>>>>>
>>>>>>
>>>>>> On 6-Oct-08, at 2:28 PM, Brian Kelly wrote:
>>>>>>
>>>>>>> A few months ago, some members from the OATH community and I got
>>>>>>> together to take a fresh look at the PAPE spec, what it was
>>>>>>> trying to
>>>>>>> accomplish, and how well it could be implemented. We started
>>>>>>> holding
>>>>>>> semi-weekly conference calls and over the period of a couple
>>>>>>> months we
>>>>>>> drafted up a slightly new take on PAPE.
>>>>>>>
>>>>>>> The main difference is that we defined a specific set of
>>>>>>> authentication methods, rather than only using high-level
>>>>>>> policies.
>>>>>>> After long discussions we found that there was too much
>>>>>>> ambiguity in
>>>>>>> the high-level policies as defined today in PAPE. We created a
>>>>>>> draft
>>>>>>> of our modified specification, termed PAPE-Authentication
>>>>>>> Mechanisms
>>>>>>> (PAPE-AM), and we are beginning to socialize the concepts in
>>>>>>> that draft.
>>>>>>>
>>>>>>> I published a blog post summarizing our motivations, and wanted
>>>>>>> to
>>>>>>> share it with the greater OpenID mailing list.
>>>>>>>
>>>>>>> http://openidtrustbearer.wordpress.com/2008/10/06/building-on-the-openid-pape-specification/
>>>>>>>
>>>>>>> I would appreciate hearing the thoughts of the readers on this
>>>>>>> mailing
>>>>>>> list. Please respond publicly, or feel free to contact me
>>>>>>> directly.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Brian
>>>>>>>
>>>>>>> --
>>>>>>> Brian Kelly
>>>>>>> TrustBearer Labs
>>>>>>> http://trustbearer.com
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> general mailing list
>>>>>>> general at openid.net
>>>>>>> http://openid.net/mailman/listinfo/general
>>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
More information about the general
mailing list