[Openid-specs-mobile-profile] New Revision of Discovery Draft

[Torsten Lodderstedt]

Hi Sebastian,

Am 22.07.2015 um 22:09 schrieb Ebling, Sebastian:
> Hi Torsten,
>
> Thank you for moving this thing forward.
thanks :-)
>
> Here are my review comments.
>
> Typos:
> Replace "I no appropriate" by "If no appropriate".
> Replace "and indicated the URI" by "and indicates the URI".
> Replace "by passing pass mobile network data" by "by passing mobile network data".
all fixed
>
> The terms IDP, OP and Authorization Server are used over the document and the message flow diagrams.
> I think we should at least remove IDP because it seems to be no OpenID term.

Good catch - I replaced all occurrences of IDP, Authorization Server, 
and client by OP and RP, respectively
>
> Chapter 3.1.3 Error Response
> I think we can copy at least error, error_description and error_uri from OAuth2 4.1.2.1 Error Response description.
> Error codes may be invalid_request, unauthorized_client, access_denied, server_error, temporary_unavailable for regular errors. We should discuss if something like discovery_failed is sufficient or if we need to be more concrete.
>
> The chapter for the issuer endpoint is also missing an error response section. I think we should use the same message format as in OAuth2 spec 5.2 without invalid_grant, unsupported_grant_type, invalid_scope but add invalid_code and discovery_failed.

I added error responses to both endpoints (utilizing some text from RFC 
6749). In contrast to OAuth, I decided to specify HTTP status code 401 
for wrong/missing credentials and 403 for unathorized access. Thoughst?

I'm not sure about two aspects:
- do we really need invalid_code or is it covered by 403?
- what is the meaning of discovery_failed? Is it any different from 
server_error?

>
> I also think we should add msisdn as optional parameter to both, user interaction endpoint and issuer endpoint.
> For the POST based flow because the app may already have the permission to query the msisdn from the device and then the user experience can be enhanced. See also Johns comment on https://bitbucket.org/openid/mobile/issues/6/general-questions
> For the redirect based flow, because the RP may already know the msisdn and only wants a secure attestation for it. I know that mobile connect is aware of privacy and designed not to tell every RP the msisdn. But I'm sure that for some RPs this will become a valid use case and then the usability can be improved. The Discovery Service may deny the request if the client is not authorized to discover the mno by msisdn.

I agree with your assessment. There will most likely be use cases where 
the RP obtains the MSISDN in a privacy preserving way. Supporting a 
direct disovery based on the MSISDN could significantly improve UX in 
those cases. On the other hand, there is not only the Mobile Connect 
privacy requirements to be considered. I see the risk of abuse of such a 
function as a universal MSISDN/MNO lookup service. We can directly cope 
with that risk in the redirect-based flow by authorizing the respective 
RP. This is (in my opinion) technically impossible in the POST flow, 
which is likely be used for native Apps. So the main use case John 
describes in the ticket you refered to also bears this risk.

I would like to have a discussion on this topic in the group.

>
> Over all, I think that the whole design will work :-)

Thank you for your feedback.

best regards,
Torsten.
>
> I had no focus on the account chooser chapters, so no comments on that.
>
> Regards
>
> Sebastian
>
> -----Ursprüngliche Nachricht-----
> Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von Torsten Lodderstedt
> Gesendet: Samstag, 18. Juli 2015 19:41
> An: openid-specs-mobile-profile at lists.openid.net
> Betreff: [Openid-specs-mobile-profile] New Revision of Discovery Draft
>
> Hi all,
>
> I just posted a new revision of the discovery draft to the repository.
> The HTML version can also be found here:
> http://openid.net/wordpress-content/uploads/2014/04/draft-mobile-discovery-01.html
>
> I revision reflects the current discovery design for both web and native
> apps as described in the web sequence diagrams. I also added an overview
> and restructured the document.
>
> Please review it and give feedback to the list.
>
> kind regards,
> Torsten.
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile