[Openid-specs-ab] approval_prompt, access_type

John is correct. The RT is issued when the user sees an approval page and the request is for offline access. On May 19, 2012 5:53 AM, "John Bradley" <ve7jtb at ve7jtb.com> wrote: > I thought that prompt=force was only required to get another refresh > token, that the first time you see the user you get a refresh just by > asking for offline. > > John > On 2012-05-19, at 12:39 AM, Nat Sakimura wrote: > > I came across just now. > > To get refresh_token, the client has to send the following parameters to > https://accounts.google.com/o/oauth2/auth. > > > - approval_prompt=force > - access_type=offline >

Filed under  //   Connect   OAuth  

Level of Assurance (LOA) - FICAM

cite #desc Description of Assurance Levels

This [..] describes four identity authentication assurance levels for e-government transactions. Each assurance level describes the agency’s degree of certainty that the user has presented an identifier (a credential in this context) that refers to his or her identity. In this context, assurance is defined as (1) the degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and (2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued. 

  • Level of Assurance (LOA) 1: Little or no confidence in the asserted identity’s validity. 
  • Level of Assurance (LOA) 2: Some confidence in the asserted identity’s validity. 
  • Level of Assurance (LOA) 3: High confidence in the asserted identity’s validity. 
  • Level of Assurance (LOA) 4: Very high confidence in the asserted identity’s validity.

Filed under  //   ACR   FICAM   LoA  

X.eaa : ITU-T Work Programme

ITU-T WORK PROGRAMME [2009-2012] : [SG 17] : [Q10/17] [Declared patent(s)]  - [Associated work]
Work item: X.1254 (ex X.eaa)
Status: Determined on 2012-03-02 [Issued from previous study period]
Approval process: TAP
Type of work item: Recommendation
Version: New
Provisional name: X.eaa
Equivalent number: ISO/IEC 29115 (Common)
Timing: 2012-09 (No priority specified)
Liaison: ISO/IEC JTC 1/SC 27, Liberty Alliance
Suject/title: Information technology - Security techniques - Entity authentication assurance framework
Summary: This Recommendation | International Standard defines four levels of entity authentication assurance (i.e., LoA 1 - LoA 4); and the criteria and threats for each of the four levels of entity authentication assurance. Additionally it: o specifies a framework for managing the assurance levels; o based on a risk assessment, provides guidance concerning control technologies that to be used to mitigate authentication threats to authentication; o provides guidance for mapping the four levels of assurance to other authentication assurance schemas; and o provides guidance for exchanging the results of authentication that are based on the four levels of assurance.

Filed under  //   ISO29115   LoA   X.eaa  

ISO 29115 : LoA for Enrollment, Credential Management and Authentication

From Evernote:

ISO 29115 : LoA for Enrollment, Credential Management and Authentication

Bc4f5b6ac0d39500bb1ac39bbb9802
- Enrollment
- Credential Management
- Authorization

Filed under  //   ISO29115   LoA   SP600-83  

[Openid-specs-ab] Definition of required and optional claims? Handling?

As a side note, I was wondering what would be the meaning of "optional" claims. Whether it is under the EU Privacy Directive and new regulation draft, the U.S. Consumer Privacy Bill of Rights, or for that matter, ISO/IEC 29100 Privacy Framework, it is clearly spelled out that the data collected must be minimized. This means that there only can be required claims. The only permissible "optional claims" probably would be in the case of "either this claim or that claim is required." For example, either phone or email is required as a mean of contact, etc. Perhaps we should spell this out somewhere in the spec., something like "privacy consideration" section in the Messages spec. My bits of food for thought. =nat

Filed under  //   ACR   ISO29115   LoA   SP600-83  

[Openid-specs-ab] Implementer’s Drafts posted with -ID1 version designations

From Evernote:

[Openid-specs-ab] Implementer’s Drafts posted with -ID1 version designations

Clipped from: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120227/001654.html
The approved Implementer’s Drafts are now also posted at these locations: · http://openid.net/specs/openid-connect-basic-1_0-ID1.html · http://openid.net/specs/openid-connect-discovery-1_0-ID1.html · http://openid.net/specs/openid-connect-registration-1_0-ID1.html · http://openid.net/specs/openid-connect-messages-1_0-ID1.html · http://openid.net/specs/openid-connect-standard-1_0-ID1.html · http://openid.net/specs/oauth-v2-multiple-response-types-1_0-ID1.html The original versions with numeric version designations remain in place. -- Mike

Filed under  //   Connect  

Howto: (Almost) Everything In Active Directory via C# - CodeProject®

Table of Contents

  • Conclusion
  • History
  • Resources
  • Filed under  //   ActiveDirectory  

    #551 - Messages - 2.1.2.1 OpenID Request Object MUST NOT include request or request_uri — Bitbucket

    Fix #551. Messages - 2.1.2.1 OpenID Request Object MUST NOT include request or request_uri

    Circula reference.

    Filed under  //   Connect   OpenID   RequestObject  

    Cross-origin resource sharing - Wikipedia, the free encyclopedia

    Cross-origin resource sharing (CORS) is a web browser technology specification, which defines ways for a web server to allow its resources to be accessed by a web page from a different domain.[1] Such access would otherwise be forbidden by the same origin policy.

    https://bitbucket.org/openid/connect/issue/550

    Filed under  //   Browser   CORS   javascript  

    Handling the Response : Using OAuth 2.0 for Client-side Applications - Authentication and Authorization for Google APIs - Google Code

    Handling the Response

    Google returns an access token to your application if the user grants your application the permissions it requested. The access token is returned to your application in the fragment as part of the access_token parameter. Since a fragment is not returned to the server, client-side script must parse the fragment and extract the value of the access_token parameter.

    Other parameters included in the response include expires_in and token_type. These parameters describe the lifetime of the token in seconds, and the kind of token that is being returned. If the state parameter was included in the request, then it is also included in the response.

    An example User Agent flow response is shown below:

    https://oauth2-login-demo.appspot.com/oauthcallback#access_token=1/fFBGRNJru1FQd44AzqT3Zg&token_type=Bearer&expires_in=3600

    Other fields may be included in the response. Your application should allow additional fields to be returned in the response. The set shown above is the minimum set.

    Below is a Javascript snippet that parses the response and returns the parameters to the server. This code is hosted at the https://oauth2-login-demo.appspot.com/oauthcallback URL.

    // First, parse the query string
    var params = {}, queryString = location.hash.substring(1),
        regex = /([^&=]+)=([^&]*)/g, m;
    while (m = regex.exec(queryString)) {
      params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
    }
    
    // And send the token over to the server
    var req = new XMLHttpRequest();
    // consider using POST so query isn't logged
    req.open('GET', 'https://' + window.location.host + '/catchtoken?' + queryString, true);
    
    req.onreadystatechange = function (e) {
      if (req.readyState == 4) {
         if(req.status == 200){
           window.location = params['state']
       }
      else if(req.status == 400) {
            alert('There was an error processing the token.')
        }
        else {
          alert('something else other than 200 was returned')
        }
      }
    };
    req.send(null);

    This code sends the parameters received on the fragment to the server using XMLHttpRequest and writes the access token to local storage in the browser. The latter is an optional step, and depends on whether or not the application requires other Javascript code to make calls to a Google API. Also note that this code sends the parameters to the /accepttoken endpoint, and they are sent over an HTTPs channel.

    Error Response

    The Google Authorization Server returns an error if the user did not grant your application the permissions it requested. The error is returned in the fragment.

    An example error response is shown below:

    https://oauth2-login-demo.appspot.com/oauthcallback#error=access_denied

    Filed under  //   Google   OAuth