[Openid-specs-heart] Initial Registration of a Patient that already has an Authorization Server with a Resource Server

[Kinsley, William]

In spirit, I agree with what you are asking, that is why in this use case Alice does provide her own AS and wants to use it with the PCP Portal’s AS/RP. At this point we have been focused on the “happy path” with these use cases; however at some point someone will introduce Mallet, our malicious user/attacker and how his role will come into play become important.

Alice has expectations and rights that the RP will respect her privacy. With that in  mind, the administrator of the RP has a responsibility to provide a level of privacy and security of the RP. This means they have to have the ability to reject an AS that wants to access the RP if the RP administrator:

1)   Does not trust the AS.

2)   Suspects that the AS is compromised.

3)   Believes the AS is malicious.

4)   The AS does not support the standards or profiles required.
The administrator needs the ability to either reject the registration request of  Alice’s AS or have the AS  register and then the RP reject the AS access requests.

In a previous discussion, my first assumption is that the AS registration would be rejected; however, Justin believes that it is more appropriate to allow the AS to register and have the RP reject it’s requests. I understand that the RP is the ultimate enforcement in how it honors the AS tokens submitted; but, I would like a better understanding of why a untrusted AS would be allowed to register in the first place?


Bill



From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Adrian Gropper
Sent: Sunday, May 17, 2015 12:41 PM
To: openid-specs-heart at lists.openid.net
Subject: [Openid-specs-heart] Initial Registration of a Patient that already has an Authorization Server with a Resource Server

I'm particularly fixated on the events and profiles around Initial Registration when Alice already has an AS.
As far as I can tell, there are only two possibilities relevant to HEART:
(A) Alice is allowed to register any AS with the new RS
(B) Alice is forced to register with another AS
Can we all agree that (B) is out of scope? If not, we will need to be clear about when Alice needs to be forced to register using a different AS.
If (A) is our path, then we need to mitigate all of the risks perceived by the RS and deal with Alice's options if the RS still refuses.
Thanks,
Adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150518/01c8d86e/attachment-0001.html>